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.
maybe it’s worth considering this connection attempt allowable by the
password-manager-serviceinterface? 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
keyringrelies on? but if there’s a recipe/strong candidate, I wouldn’t try to go vigilante.)