On every start, nextcloud-client will throw the following message/error:
Using KDE Neon:
jeffrey@tranquil:~$ snap --version
snap 2.31.1
snapd 2.31.1
series 16
neon 16.04
kernel 4.13.0-36-genericLooks like nextcloud-client snap specifies the password-manager-service interface. So maybe try this:
snap connect nextcloud-client:password-manager-service
Then re-start the application. If it works then perhaps this should be an auto-connected interface. @jdstrand is that allowed?
2 Likes
Thanks Popey! That works indeed 
Perhaps the maintainers of the package should be notified so this can become a built-in feature? Or is that not allowed?
1 Like
Yay! Good news. I think @kyrofa can help here
1 Like
Access to the password manager essentially means access to all unlocked passwords in the manager (e.g. the login keyring). This is a risk that in my opinion should be opted-into, which is why I havenāt tried to get that interface auto-connected.
1 Like
I understand that entirely. Could a message be displayed for the people who want to have it connected though? I wouldnāt have thought of the solution Popey suggested - let alone searched for - since I didnāt know the option exists.
There is something to be said for the use case of ājust wanting Nextcloud-client without having a PPAā. Though, I do understand why people would want the run the client confined.
Regarding confinement, I could reach my ~/Documents from within the Nextcloud-client snap. Which is desired behavior for me, but perhaps not for some who desire the confinement.
Meh. Honestly I donāt like the home interface auto-connected either, or X, orā¦ am I being too paranoid? Is this just hurting usability? Should we look into getting the password manager auto-connected for this snap? Honestly looking for feedback here.
Making code changes to determine if weāre running in a snap and if we donāt have access to the keyring isnāt super trivial, and I suspect will not be looked upon favorably by upstream (which is even further away than the Nextcloud client, since they just theme the ownCloud client).
I do wonder what weāre expecting users to do here. Are we expecting them to just āknowā that an interface exists (or what one is)? Are we asking a little bit too much from users who are expecting to click āinstallā and get a working application? I donāt know of any other platform (mobile or desktop) where users are expected to enter arcane commands to get the app to function.
I can forsee, if we donāt āfixā this, that developers will either not adopt the platform, or use workarounds. Perhaps they might popup dialogs which punch the user in the face and tell them to run snap connect app:interface or will just tell people to copy/paste things into the terminal, which is exactly what weāre trying to get away from.
Iām keen to learn what the long term plan is here for usability in terms of connecting interfaces.
Iām keen to learn what the long term plan is here for usability in terms of connecting interfaces.
@jdstrand, mind sharing your vision here?
I honestly think we need a gui panel in system settings where we can set our own default policies for all the interfaces, with the ability to change from the defaults on a per-app basis. It makes no sense to me that joystick capabilities are blocked for games but any app can read all my home files and send them to a remote server without permission.
As I recall it, the idea is that weād have something checking for denials, and let the user know how to resolve them via a notification / indicator / thing.
I was hoping Iād be able to play with a first pass of that, but my plate has never been less than overflowing this time around.
We need something besides the command line so that people know what the snap is expecting. Personally, I would be surprised to install this snap find it had access to all my passwords behind the scenes so +1 for not auto-connecting. Iāve been hoping for the gnome-software changes to surface this to the users, which is the official plan of record.
This is essentially what snappy-debug does, but I suppose in this case rather than suggesting all interfaces that could resolve it, it would only suggest the ones that the snap already requested but werenāt connected. Note that snappy-debug needs a lot of work to do its current job better (eg, proper dbus and unix support) because libapparmor and the python userspace donāt support everything yet. snappy-debug does āokā, but, like you, too many things are prioritized over it.
Iām guessing you were thinking about writing this tool in Go, which is obviously possible, but youād need to write the Go bindings for libapparmor (could use the C library) but even more work is reimplementing the python userspace tools since they are what make the suggestions, but even they need work (the improvements to snappy-debug are precisely to improve the apparmor userspace tools and use them).
Incorporating an indicator/notification is possible, but understand that this is putting confinement violations front and center in the UX for snaps for regular users. I would caution against this since this is what SELinux did and many turn it off as a result; also some denials are not indicative of a problem, just occasional noise in the logs that you wouldnāt want to surface to the user. Furthermore, gnome-shellās notifications are difficult to work with (I know since Iāve had to make adjustments to aa-notify): either the messages are short lived and people miss them, or they are long lived and fill the notification area to the point where a misbehaving snap might fill the notification area with thousands of messages which grinds it to a halt for scores of seconds when you click on it. Lastly, presenting this to the user would need to be done extremely carefully-- we wouldnāt want to suggest that a game have network-manager or network-control connected since the game could then have access to all networking.
IMO, we need to fix gnome-software center first. Then the services that applications use should become trusted helpers (ie, like portals or the various services on Ubuntu Touch) so that applications can just talk to these safe services. The password-manager-service interface being held up here is exactly the type of problematic interface we donāt want to just hand out-- it was not designed with application confinement in mind. It is an old technology and the interface is considered transitional until something better is implemented.
Can the situation be improved? Absolutely. However this needs careful design (it is something @mpt has and continues to think a lot about; there are the bits for the user, what to present, parsing the logs (donāt get me started on journald format breakage), rate-limiting, etc, etc, etc) and proper resourcing and prioritizing for a good implementation.
1 Like
This has turned into a very informative and thoughtful thread! Knowing the plan of record, I still think this interface should be opt-in for this snap (particularly considering that the snap works without it, one just needs to enter a password every time). Sounds like things should improve.
It really depends on the approach. From a security standpoint, I agree with you entirely. From a usability standpoint, it lacks functionality that would work by adding the PPA - thus resulting in people refraining from using the snap.
It really depends on what the bigger focus is. And, as mentioned before, I could see a graphical pop-up doing the trick. Pretty much like the android āApp X wants access to your contacts. Allow?ā approach.
I donāt mean to say that the current situation is good enough. I think we can all agree thatās not the case! What I mean to say is that, while the current situation isnāt ideal, it sounds like things are moving in the right direction to be much more user-friendly.
The contextual prompting is what I was referring to with the ātrusted helpersā approach. secret-service and the other support password managers have no concept of this, but a properly designed trusted helper (in this case, password manager) service would prompt per-snap that requested access, recording the userās answer in a per-user database (this is what Ubuntu Touch did with several services).
I didnāt mention this before, but for @chipacaās idea of monitoring logs, by the time the snap tries to access the service and there is a security policy denial, it is too late for true usability since the app saw the failure and proceeded (ie, the idea of monitoring for denials to prompt for interface connections is only helpful for the next time the snap tries the access).
It is possible for snapd to have a dbus proxy for certain services that intercepts the dbus calls, checks that the interface is connected and if not prompt the user to connect the interface. Note that this is happening with the privileges of the user-- interface connections are system wide for all user and require privileges, so if the user isnāt an admin, this doesnāt work. This proxy could instead incorporate the trusted helper approach and maintain its own db of per-snap accesses to different services, in which case, because snapd is doing the proxying/prompting, then the interface could be auto-connected (or allowed in the the ādesktop-legacyā interface). This would also only work for DBus though, since we canāt reasonably intercept file accesses at this time (perhaps we can in the future).
I maintain that we should follow the approved course of action which is a gnome-software install prompt for transitional interfaces and continue to work with upstreams on trusted helpers, whether they be portals services or something else. We continue to have snap declarations to grant auto-connection where we want to use that.
As end user I am really frustrated by this issue. I just installed Ubuntu 18.04 and it took me some days to find this topic: I had to lose time to find a way to have my installation working as it was in Ubuntu 16.04.
I was thinking about switching to PPA: I gave snap a shot only because it is the predefined way to install the app through the store, but these kind of issues are really annoying.
I fully understand the security implication, and I applaud the idea to find a better approach to data management, but I cannot stand that on an LTS release the default version of an application is broken on the usability side, and I have to look through forums to find a solution
1 Like
connecting the password-manager-service interface should be easily achievable in gnome-software in 18.04:
2 Likes
Wow, never noticed that, indeed is easy if you know it, thanks!