Personal-files access request for KeePassXC

Good day, requesting the ability to use the personal-files connector for KeePassXC. Not sure exactly how to format this request, but we have a Pull Request submitted that migrates us over to fully leverage the new capability in XDG-Desktop-Portal. See here: Snap: Improve Web-browser Native Messaging host functionality by JGCarroll · Pull Request #10906

This request will allow KeePassXC to write native messaging configuration files (.json files) to the appropriate locations for various browsers. Doing so eliminates the need to run a script we created to overcome this limitation/security-feature of snaps.


I’ll give it a go (Seeing as I’m presuming you’re in favour!)

We’ve added the following plug:

    interface: personal-files
      - $HOME/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.config/chromium/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.config/google-chrome/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.config/microsoft-edge/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.config/vivaldi/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.config/BraveSoftware/Brave-Browser/NativeMessagingHosts/org.keepassxc.keepassxc_browser.json
      - $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Browser/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

The name violates normal conventions because the normal conventions wouldn’t apply here. (E.G the convention of using dot-home-slash-local-yadayada). I believe the purpose of the plug and it’s name is appropriate in this scenario and the exception warranted, it’s clear as can be what the plug is for.

We’d like this to be automatically connected as it enables the KeepassXC snap to work identically to regular KeepassXC for the purposes of the web browser integration. With this interface granted, an Ubuntu user with the default Firefox snap and KeepassXC snap will see the two work identically to their native equivalents (N.B the portal popup confirmation happens but I’m counting it because that’s a conscious decision on the Portals, also there’s no portal popup for native browsers which this also benefits).

Ultimately I’m hoping the paths should be self evident, KeepassXC is clearly the owner of these files and these files are exclusively designed to be used with KeepassXC’s Browser extensions, no other app would have reason to interact with them.

So Tl;Dr, great UX improvements for basically 0 security exposure, those files are only ever used for the purpose of Native Messaging in Web Browsers, and the Web Browsers themselves add their own checks so both sides of the communication have safeguards. I believe this is well within reasonable user expectations to autoconnect :slight_smile:

And to prove how much I considered it, I even made this Proposal: Native Messaging Host Interface

1 Like

N.B I’ve just spotted an error in the above, namely the Tor Browser line gives full access to the Tor Browser native messaging hosts folder, whereas it should only be the one KeepassXC file.


I’ll update the Github PR with the file extension correctly added now, as is on a7849e4 this wouldn’t fly but is genuinely just adding the file name.

Edit: This is done, I’ve updated the plug in the post above to match how it should have been.

Sorry off the topic.

But in snap store, keepassxc page shows

NOTE: KeePassXC no longer supports this distribution method.

Is it still true?


The requested files belongs to the snap, I am not sure about the naming convention of the plug, otheriwse it looks good to me, +1 from my side



True in the sense that we don’t respond to bug reports specifically for snaps. We still maintain the distribution pathway though.


I pushed a test build with the above plug, it is pending human review in the store now.

+1 from me for granting write access to the requested files. It is a well known use case for browser native-messaging and files name (org.keepassxc.keepassxc_browser.json) is clearly owned by keepassxc. I can agree with making an exception naming convention for personal-files interfaces in this case. The purpose of the interface should be evident enough with the proposed name (browser-native-messaging)

1 Like

Specific write access to these directories should not be needed since this is supported by XDG Portals etc - ie. Both the firefox and chromium snaps support native messaging without any such specific access. However I am not that up-to-date with how this is actually achieved. @jamesh are you able to shed any light here? Thanks.

1 Like

The browsers look in their respective native-messaging-hosts folders for files placed there by other applications to allow extensions to launch the requested native messaging proxy or app. Somewhat easy to read breakdown: Web-to-App Communication: The Native Messaging API – text/plain


The portals for native-messaging grant the browser the ability to access the system wide keepassxc.proxy via e.g the Firefox snap, but the browser still needs to actually know that KeepassXC is available to use, which is what writing these manifests are for.

The portals don’t assist with creating those manifests in the first place. The status quo would be most apps don’t implement this functionality and it probably doesn’t come up much. Ones that do might have a strong bias to not be sandboxed and so it feels like stuff “just works” but there’s a very specific step the apps are taking to inform the browsers they exist.

Specifically then, the FF snap is actually looking at $SNAP_REAL_HOME/.mozilla rather than its own snap $HOME because that’s where every non-sandboxed app would place them, so on with the rest. Ideally the portals would provide an alternate way to advertise native-messaging support themselves, but from what I’m aware that’s not the state they’re currently in.

Also, whilst KeepassXC is sandboxed, the actual browsers may not use the portals at all, so for e.g Google Chrome from Google’s own Apt repos, it accesses KeepassXC’s snap without portals, which needs the files in these places again. From the proxy’s perspective, it doesn’t care if you’re sandboxed or not, it’s just writing to STDIN and STDOUT.

So providing this interfaces also fixes classically packaged browsers who don’t have portals, as well as OS’ which don’t have James’ (currently) downstream patch. I’d expect the Firefox RPM package in Fedora to work with the KeepassXC snap with this change for example.

1 Like

At present, the native messaging portal solves the problem of letting a sandboxed browser access native messaging hosts outside of the sandbox. We haven’t done anything yet to support the case of sandboxed native messaging hosts.

A proper solution would likely consist of either:

  1. Have snapd write out manifest json files on behalf of the snap, making sure the command in the json file actually calls the snap.
  2. Have xdg-desktop-portal somehow know about snapped native messaging hosts and treat them specially.

(2) has the downside of not working for unsandboxed browsers that don’t use xdg-desktop-portal.

As for the personal-files approach: while it can work as an interim measure, it also creates a trivial sandbox escape. If the command the snap writes into the manifest JSON isn’t the /snap/bin/xyz wrapper, then you’ve got code execution outside of the sandbox. I’m not sure how you balance that risk.

1 Like

Regarding the arbitrary executable concern, there’s a huge advantage in the browser ecosystem that I think nullifies this particular concern.

The native messaging API is exclusively for web extensions/addons. Given all the security concerns with malware hijacking browsers via their extensions systems, for years all non-developer focused browsers have key signing requirements in the same manner as snap itself. E.G., for Firefox, you must upload the addon to Mozilla to review, who then give it the blessing to be distributed. Users will have guarantees from the package manager that the browser is trusted, meaning there’s keys involved the whole way.

This review process would ensure that there’s no other programs that would try to access KeepassXC’s manifest file, other than the official KeepassXC browser extensions themselves, and that extension is set up to have an explicit authentication mechanism to ensure that it’s talking to the real KeepassXC.

So in general, because we can say the files will only ever be used by KeepassXC’s own browser extension, we can ignore a theoretical attack from KeepassXC itself, that’s just the general aspect of trust in the publisher, and specifically, it’s trust in the publisher of the addon, which doesn’t relate to the snap side of the problem.

And it’s trust in the publisher then that I think merits this for autoconnection. KeepassXC is a password manager. My instance has quite literally all my passwords for every online account, bank accounts, my Snapcraft/Ubuntu One account, etc. It also has my SSH keys (since the app has functionality to manage SSH Agents).

Basically, there’s literally no need for an exploit to be required. The app could trivially send all of this decrypted to some hacker if it wanted to; the trust is that the app is built securely by trusted publishers.

As an extreme example, KeepassXC could trivially escalate itself to root on my PC by shipping an SSH client in the snap, taking my SSH key, and remotely logging in as root. I’d hope people agree that’s something they have trust wouldn’t ever be allowed to happen.

As such, given the UX improvements, and encouraging people to swap to adopting Password Managers to begin with, there’s no real practical security lost in my personal opinion in real world circumstances. The trust in this application is already immense and there’s cryptographic security & reviews on all sides to prevent that kind of tampering from being a real world concern. Meanwhile the usability improvements for the snapd ecosystem are there; including not having people Google how to work around it via running an external script (hopefully the official one, but can we be sure?).


So, any movement here? Our current release is awaiting your manual review.

1 Like

Re-reading my lengthy post above, I thought it’s worth tl;dr-ing.

Tl;Dr a hypothetical attack using this file requires social engineering to a pretty insane degree. You’d have to convince the user to install a developer browser and then a developer addon and also either the KeepassXC snap has been hit by a severe exploit that somehow can only exploit the hardcoded strings (There’s easier ways to abuse a buffer overflow, given all the secrets people would usually exploit for are already in the snap) or the user is running an unsigned version of it where the review process can’t apply. You’d need all of these elements to come together for these files to be a problem, and any singular one of them is already unlikely, nevermind the full chain needed.

1 Like
  1. Have snapd write out manifest json files on behalf of the snap, making sure the command in the json file actually calls the snap.

I tend to agree with @jamesh, it looks like a much better solution. However, in this concrete situation I’ll still be happy to support this request for KeePassXC until a better alternative exists. At the end of the day, users are putting their trust in this application by giving all their precious secrets to it. A malicious/compromised KeePassXC snap could just send all users’ passwords over the wire. This request seems also be necessary to enable the browser integration use case.

1 Like