Ok, so this is only about finding/installing private snaps?
Yes, just for access to private snaps.
+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.
@reviewers - can others please vote?
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”…?
That’s a real shame.
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.
I am fine with not auto-connecting personal files. If a user has to use the command line to login anyway, they could also connect.
@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:
plugs:
hostfs-usr-share-applications:
interface: system-files
read:
- /var/lib/snapd/hostfs/usr/share/applications
dot-snap-auth-json:
interface: personal-files
read:
- $HOME/.snap/auth.json
and reupload. Once you do that, we can manually approve until the change is in production.
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.
1 Like
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.
- Daniel
@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.
If there is a login ui, why wouldn’t it just write out to $HOME from the perspective of the snap, ie ~/snap/snap-store/current/.snap/auth.json?
Interesting, then it might be even nicer: “if you want to get notified of firmware updates, connect this manually”
Not auto-connecting fwupd would be a regression from today’s gnome-software in Ubuntu. And without connecting it we can’t check for updates.
Yes, it will just use $HOME for reading/writing. So if it has a different $HOME to the snap command line then it will have a separate credential. For the best user experience you’d only have to login once from either the command line or the GUI. What we can’t do is have read access to the command line credential but not write access - we need read/write or use separate credentials.
I think separate credentials will be fine