We (Canonical’s Data Platform team) released a new snap for MongoDB ecosystem. It’s a GUI client (electron app).
I’m requesting auto-connection on two interfaces for this application.
name: mongodb-compass
description: |
MongoDB Compass lets builders explore their data, run queries and
aggregations, and refine their data models through an easy-to-use visual
interface.
snapcraft: link to snapcraft.yaml if publicly available
upstream: github.com/mongodb-js/compass/
upstream-relation: This snap is maintained by Canonical’s Data Platform team. I am a maintainer and contributor to the upstream packaging repository.
plugs:
system-observe:
interface: system-observe
request-type: auto-connection
reasoning: It is used by the packaged mongodb-compass client for system-level runtime information. MongoDB Compass is an electron app. Without this integration it gets errors when trying to read runtime resources to provide system information.
password-manager-service:
interface: password-manager-service
request-type: auto-connection
reasoning: It is used by the packaged mongodb-compass client to store the connection information. Without this, connections cannot be stored between application restarts.
I read the post and the documentation on snapcraft about the secret portal, but y understanding was that it did not work with electron.
If we cannot get the password-manager-service interface I’ll follow the same pattern as element-desktop did with a launcher script.
I’ll give a try to the secret-portal here and report if it works but my initial testing did not seem to work as expected.
As @ogra mentioned, we generally discourage auto-connecting password-manager-service. When connected, your snap gains access to all stored secrets in the user’s password manager, and conversely, your snap’s own stored secrets become accessible to any other application with that interface connected.
Thanks for understanding and for your willingness to try the available workarounds!
Regarding the system-observe interface, could you provide more details on what Compass reads via system-observe and why it requires that access? This will help us determine if system-observe is the right interface and if auto-connection is justified.
For password-manager-service: I gave a try to remove the interface, but it fails with an AppArmor denial which is consistent with the example that was given in the section about Electron Apps in the docs (cf the example from the docs)
[3232957:0924/103149.644721:ERROR:dbus/object_proxy.cc:572] Failed to call method: org.freedesktop.Secret.Service.ReadAlias: object_path= /org/freedesktop/secrets: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.2227" (uid=1000 pid=3232957 comm="MongoDB Compass " label="snap.mongodb-compass.mongodb-compass (enforce)") interface="org.freedesktop.Secret.Service" member="ReadAlias" error name="(unset)" requested_reply="0" destination="org.freedesktop.secrets" (uid=1000 pid=22409 comm="/usr/bin/gnome-keyring-daemon --foreground --compo" label="unconfined")
For system-observe, I get some AppArmor denials for ListNames:
Failed to call method: org.freedesktop.DBus.ListNames: object_path= /org/freedesktop/DBus: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.2299" (uid=1000 pid=3417633 comm="MongoDB Compass " label="snap.mongodb-compass.mongodb-compass (enforce)") interface="org.freedesktop.DBus" member="ListNames" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
My understanding is that it investigates the CPU features for proper reporting.
I’ve seen also that as it embeds a mongosh implementation, it uses it for the same reasons as in this topic. I don’t know exactly if it uses the ListNames method for anythingelse.
password-manager-service: The AppArmor denial you’re seeing is expected when the interface is disconnected. It confirms Compass (via Electron’s keytar) attempts to talk directly to org.freedesktop.secrets (gnome-keyring) using the legacy Secret Service D-Bus API. That is exactly the code path the Secret Portal migration is designed to replace.
Auto-connecting password-manager-service would bypass that migration path and grant Compass (and transitively any other connected app) access to all secrets in the user’s keyring, which is the exposure we discourage.
In the meantime, users who specifically want full keyring integration can still manually connect the interface, and Compass can detect that state using snapctl is-connected password-manager-service.
system-observe: The ListNames call is directed at org.freedesktop.DBus to enumerate all available service names on the session bus. However, system-observe grants privileged read access to process information under /proc, while the dbus interface grants access to specific, well-known service names (e.g., org.freedesktop.Secret.Service), rather than generic bus enumeration.
This denial is common in snapped Electron apps because they call ListNames proactively during startup to probe for available services. It is typically non-fatal, as the app should catch the AccessDenied error and fall back gracefully.
Regarding the CPU/hardware aspect: reading CPU or hardware details (e.g., /proc/cpuinfo) falls under hardware-observe rather than system-observe. If the primary need is reading CPU/hardware information, hardware-observe would be the appropriate interface to request.
Overall, it would help us evaluate this if you could:
Share the actual /proc denials Compass hits separate from the ListNames D-Bus denial.
Confirm whether the requirement is genuinely per-process info (system-observe) or CPU/hardware info (hardware-observe).
password-manager-service: The AppArmor denial you’re seeing is expected when the interface is disconnected. It confirms Compass (via Electron’s keytar) attempts to talk directly to org.freedesktop.secrets (gnome-keyring) using the legacy Secret Service D-Bus API. That is exactly the code path the Secret Portal migration is designed to replace.
I’ve tried disconnecting the interface, but then the user loses it’s password upon restart of the application.
I do have a valid XDG portal running on my machine and the desktop interface connected.
But no worries, if I don’t get auto-connect for this one, we’ll find a way.
Then: I don’t see any /proc denials, (which bugs me a lot). Adding hardware-observe does not change the overall behavior and does not silence the ListNames
I however see a lot of ListNames denials that don’t seem to block the execution from happening.
Appreciate you saying you’ll find a way, we’re here to help with the migration if you need it.
In that case, system-observe is not actually needed (but I really get your frustration ).
Considering the other denials you found:
/dev/char/195:254 and /dev/char/195:0: Major 195 is the NVIDIA GPU driver. These are symlinks to /dev/nvidiactl and /dev/nvidia0 respectively. This is a non-fatal denial, as the GPU is still accessible through the primary device paths.
org.bluez / GetManagedObjects: Compass (via Electron/Chromium) is probing the BlueZ Bluetooth service on the system bus, likely for the Web Bluetooth API. Similarly, this is non-fatal as the snap doesn’t need Bluetooth for its core functionality. (In case you need this, the bluez interface would cover it, but it doesn’t auto-connect, so we would need to cast votes for it too).
So in the end, I could go away with the system-observe being removed.
For password-manager-service, I’ll use a launcher script if I can’t get the auto-connection.
I’ve tested without, and I’m not contributing on upstream codebase so there’s no way I can get them to fix it.
@medib For ref: no autoconnect for password-manager-service and apparently system-observe is not needed.
).