Our snap of gnome-software which is published under the name snap-store now has the ability to manage packages installed on the system via apt/deb as well as update firmware. I’d like to request auto-connect of some additional interfaces needed.
system-files: read access to /var/lib/snapd/hostfs/usr/share/applications
Required to query for apt installed applications
personal-files: read access to $HOME/.snap/auth.json
Required to share the token for snap login with the snap command line
appstream-metadata
Access required to query metadata about apt packages and list installed apt packages
packagekit-control
Access required to install and remove applications via apt
All of these make sense to me (indeed, packagekit-control was written for this snap), except the personal-files request. Can you explain that one in a little more detail?
When you login to the snap store with snap login it stores a token in your home directory. GNOME Software doesn’t provide a login UI for that anymore, so the only way we can access private snaps is if you’ve logged in via the command line and snap-store has access to read that token.
Ok, I thought I remembered there was a login UI. Now that it is removed, what happens when the user tries to install a snap without having run ‘snap login’?
+1 for use of and auto-connect of system-files for read-only access to /var/lib/snapd/hostfs/usr/share/applications (with an interface reference of ‘hostfs-usr-share-applications’). +1 for auto-connect of appstream-metadata, packagekit-control and fwupd.
+1 for use of personal-files with read-only access to ~/.snap/auth.json (with ‘dot-snap-auth-json’ as the interface reference) but -1 to auto-connect. Since the user already has to be instructed to go to the command line to perform ‘snap login’ for a private snap, the user can also perform the snap connect or just install the one or two private snaps from there. I’m willing to reconsider my vote on this pending other discussion.
Re: auto-connect for auth.json, @jdstrand is there a significant security issue with this? Auto-connect would streamline the user experience in this case (the reasons for the changes in GNOME Software notwithstanding).
Why is a graphical store which up until very recently featured a “Login to Snap Store” button now forcing users to snap login on the command line? Pretty sure we discussed this, and the “Login to Snap Store” button should be put back in. Negating the argument @jdstrand puts forward for “while you’re on the command line”…?
I’m not so much concerned about the security for this snap since it is so privileged as I am for setting a precedent for accessing this file, which is an unusual access for a snap.
+1 to use and auto-connection of each of these given the specific constraints. Each covers core and expected functionality for this snap and the UX would suffer without them.
It sounds like this is required because of the lack of UI (i.e. the UI did not need access to this file and used polkit as I recall). Once the UI is back (which sounds like is in the works) this will not be necessary. Does that sound accurate? I will assume so until corrected.
The UX of automatically connecting the personal-files interface to use the snap login token is poor. It means the UI will magically be showing private snaps or not, depending on whether or not the user had already run snap login. This is in contrast to the polkit integration, which would force the user to login in right then and there order to see such things. In this way, requiring the connection of the interface seems similar.
Beyond this, though, it looks like the level of access provided by polkit and that provided by snap login are not the same (it seems polkit has less). I agree with @jdstrand that it would be a bad idea to set precedent for accessing this file automatically. +1 to using personal-files to access the token, but -1 to autoconnection.
In the interest of the impending feature freeze, I am going to grant what has enough votes, ie:
for use of and auto-connect of system-files for read-only access to /var/lib/snapd/hostfs/usr/share/applications (with an interface reference of ‘hostfs-usr-share-applications’)
for auto-connect of appstream-metadata, packagekit-control and fwupd
use of personal-files with read-only access to ~/.snap/auth.json (with ‘dot-snap-auth-json’ as the interface reference) without auto-connect
These all have 2 votes for, 0 against. Granting all of them, this is now live.
We can discuss auto-connect for personal-files for the duration of the voting period. If @reviewers feel any of the above is in error, please speak up and we can adjust the snap declaration.
@kenvandine - I’ve updated the review-tools for this just now, but it will be a little while before it is in production. Please adjust your snap.yaml to use:
There is a new login dialog in gnome-software 3.35.91-0ubuntu2 (focal). This writes to ~/.snap/auth.json, so we’d need read/write access to this. Since this dialog exists, it would be confusing if the interface isn’t autoconnected.
Yay for omnibus requests Thanks for the detailed explanation on each request.
I’m +1 on use/auto-connect of system files, it’s a shared system directory, nothing personal/sensitive there it seems.
+1 on personal-files as required, I’m also +1 to auto-connect it, since I feel the connection between snap-store and your snap auth.json is sort of implied by the name. It’s just a vote though, if the tally is against it then not auto-connecting sounds reasonable though less slick.
+1 on appstream-metadata with auto-connect since metadata also sounds like it’s not terribly sensitive.
+1 on package-kit control with auto-connect as it sounds like the raison d’être for a software store-type of snap.
+1 on fwupd but -1 to auto-connect. Installing firmware updates sounds like it’s not frequently done and it doesn’t sound far-fetched to ask the user when a connection is needed, until then best not to blanket auto-connect this potentially sensitive functionality.
@roadmr - I will be sure to keep an eye on this tally. Do note that snap-store needs to talk to fwupd in order to inform the user when there are firmware updates to apply. The DBus api is also protected via policykit.
Thanks for the detailed explanation on each request.