Hello,
Sorry if it’s a dup. I am about to publish a (brave but beta) app in a snap, that leverages password storage. For this, a Python package, keyring is used currently.
Even having connected the password-manager-service interface to the snap, snappy-debug will present me with something like the below around startup:
= AppArmor = Time: Jan 7 13:14:54 Log: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/freedesktop/secrets" interface="org.freedesktop.DBus.Properties" member="Get" mask="send" name="org.freedesktop.secrets" pid=23803 label="snap.focus-project.focus-project" peer_pid=2061 peer_label="unconfined" DBus access
A shallow debugging attempt seems to confirm that this relates to the essential operations of that package (i.e. I get back a “None” instead of a password that has just been stored, then a very telly error message, though I believe it wasn’t 100% replicable).
The only thing I can say about dbus is an inconfident ‘let’s change the subject’, but am guessing just by the look, the above could be something to consider part of the password-manager-service? My wild guess is that keyring, being a multi-platform creature, tries to scan for the available backends and this might be a less frequently experienced situation from AppArmor’s perspective.
So
-
maybe it’s worth considering this connection attempt allowable by the password-manager-service interface? currently I chose network-control (alternatively mount-observe was suggested by snappy-debug). I feel like, however, either of the latter might be difficult to explain to the users (if any, ever, of course 
)
-
if there’s a standard Python package that works more in tandem with snapcraft in your experience/opinion for storing credentials, what would that be? (maybe I should just try to narrow things down to secret-storage, which keyring relies on? but if there’s a recipe/strong candidate, I wouldn’t try to go vigilante.)
Thank you!
Janos
This access should be allowed by the interface, but the interface is not automatically connected. Did you connect it with sudo snap connect focus-project:password-manager-service? You can see if it is connected using snap connections focus-project.
Thank you for getting back!
I have made a lot of attempts, theoretically - apart from human error - yes, it was a scenario that I went through, and yes, there was the moment (or at least I announced to myself it as such) when without that interface the app failed, then adding that one interface got things going.
I’ll give it a retry at some point (expect no more than 1 day) just to make sure I did definitely connect as there’s a lot of crunching these days, so anything could have happened.
Thanks again!
So, yes. 1. There really seems to be/have been some problems around that dbus-based interface somehow, but 2. Seems like they are getting fixed/the fix is propagating through the distros? Solves my problem anyway.
- As a good thing, right now, my nsap seems to work (launch up) on Ubuntu 20 without the network-control interface, I’m almost certain that it wasn’t the case when building/testing that same snap
- I am 100% sure I’ve tried (okay, still not necessarily when debugging into what was going on, but) at the time creating the snap, only connecting the
password-manager-service interface and it did not suffice
I actually got the recommendation of network-control or mount-observe after connecting password-manager-service from snappy-debug
but I think this all happened on my build Ubuntu 18.04
- it seems to work fine on my Ubuntu 20.04 with solely connecting the
password-manager-service interface
- The below
snappy-debug output screenshot is from a fresh install of LUbuntu 20.10 that claims itself up to date. Weirdly, despite in this case both interfaces are connected (password-manager-service, network-control):
Not sure if it’s just better to wait then, or do more experiments? So I’ll just wait. Thanks for the reply again. If you need anything from me, let me know!
You can try it for yourself by
snap install focus-project --beta
(No need to configure it up, things should turn out right on app launch.)
Also though snappy-debug does mention the network-control interface when disconnected, it does so with a reasonable error message, and as mentioned, the app launches fine without it on the ‘normal’ Ubuntus (possible that I copied a ‘stale’ error entry into the opening post?):
= AppArmor =
Time: Jan 13 02:11:34
Log: apparmor="DENIED" operation="open" profile="snap.focus-project.focus-project" name="/proc/4681/mounts" pid=4681 comm="focus_project" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /proc/4681/mounts (read)
Suggestions:
* adjust program to not access '@{PROC}/@{pid}/mounts'
* add one of 'mount-observe, network-control' to 'plugs'
