Snap: Cannot open/saveas a database, open url, or open/save attachments

[l0f4r0]

Overview

My KeepassXC snap has been automatically upgraded recently to v2.7.0 on my Linux Debian 10. I cannot open any database since then so it's a really bad situation for me...

Steps to Reproduce

1. Launch KeepassXC
2. Click on "Open an existing database" at the center of the main GUI window (or click on menu "Databases" > "Open a database...")
3. Nothing happens

Expected Behavior

Upon clicking the button "Open an existing database", I should have a popup window telling me to choose a database to open

Actual Behavior

There is no popup window allowing me to choose a database to open inside KeepassXC

Context

Nothing special except the followig console lines when launching KeepassXC snap via the CLI :

Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
YubiKey: Failed to establish PCSC context.
YubiKey: PCSC interface is disabled or not initialized.

KeePassXC - Version 2.7.0 Révision : 20c9ac1 Canal : Snap Qt 5.15.3 Operating System: Linux Debian 10 64bits Desktop Env: XFCE 4.12.5 Windowing System: X11

[phoerious]

This looks some sort of configuration issue on your system. Can you try the AppImage from the downloads page?

[l0f4r0]

Workaround so far: open my database through the command line. It works.

I will give a try to the AppImage later.

[pabo3000]

Same here. If started from cmdline you can see that menu option Database/Open Database ... is not working either. Same for Save Database As ... and Save Database Backup As ... and Database/Import. (I use the snap.)

[dmell]

I am not sure if I am encountering the same problem, but I also cannot open my database directly from the GUI, after the update. The interface shows the following error message:

Failed to open /home/dmell/snap/keypassxc/1522/Passwords.kdbx. It either does not exist or is not accessible.

Workarounds: launch keepassxc from the terminal, or copy the database in another folder (/tmp/ worked) and open that one. Could it be an issue related to snap permissions?

[droidmonkey]

Yes that is a snap permissions problem. Do not store your database in the snap folder. Just put it in your home directory or documents or wherever else

[dmell]

Thanks! Dumb question maybe, but for curiosity, why does it work even from the snap folder, when launching keepass via the cli?

[droidmonkey]

I have no idea, snaps are beyond complex to me, they do whatever they want.

[TomBaxter]

First off, thanks for keepassxc. I love it.

"File /home/tkb/snap/keepassxc/1522/Passwords.kdbx does not exist."

I will follow droidmonkeys advice and not store the kdbx in the snap directory. Actually, I thought I had been doing that. For anyone else having this issue, your kdbx may still be available. Though I don't know if any data is missing.

tkb@sisyphus:~$ ls -l snap/keepassxc/15*/Passwords.kdbx -rw------- 1 tkb tkb 326757 Mar 10 15:28 snap/keepassxc/1537/Passwords.kdbx -rw------- 1 tkb tkb 326757 Mar 10 15:28 snap/keepassxc/1541/Passwords.kdbx

tkb@sisyphus:~$ ls -l snap/keepassxc total 12 drwxr-xr-x 4 tkb tkb 4096 Mar 10 15:28 1537 drwxr-xr-x 4 tkb tkb 4096 Mar 10 15:28 1541 drwxr-xr-x 3 tkb tkb 4096 Dec 24 18:32 common lrwxrwxrwx 1 tkb tkb 4 Dec 24 18:32 current -> 1522

Caveat. I'm only guessing. I have no knowledge of the inner workings of snaps. It seems that with each update the kdbx is copied into the new version. I assume the "current" link is supposed to get updated. I also assume that snap only keeps the last two versions. so 1522 was deleted and the link was not updated.

So the kdbx is still there. But as OP said, version 2.7.0 seems to have a bug. "Opening an existing database" just doesn't work. No error or response of any other kind.

Gonna fiddle with it a see if I can find a workaround.

[ovals12]

I have the same issue as reported here. Snap installation of keepassxc. Since the yesterday's upgrade to 2.7.0 it is not possible to open database or save database as. Menu: Database -> Open Database does nothing.

When I open recent database and want to save it as other database using menu: Database -> Save Database As, it does nothing.

I tried completely removing snap and make a clean installation but the behavior is the same.

The same version 2.7.0 installed via ubuntu PPA works fine without above issues.

[droidmonkey]

@ovals12 what is your exact environment? Ubuntu version XX.XX and desktop env (KDE/GNOME/XFCE)

[TomBaxter]

I'm 21.10 GNOME

I think it's just the snap image unable to open files. Couldn't find a place to report to the snap maintainer. I switched to the AppImage and all is well for me now. I think this has pushed me from snap being something I hate to love, to something I love to hate.

[TomBaxter]

Say... I saw another bug report saying they can't open an URL. I can reproduce that with the snap. In the AppImage it works fine. So I wonder if it isn't that the snap can't open files but instead it's having trouble with xdg-open?

[droidmonkey]

I think there is a bug in snapd on 21.10, that is the common denominator. Please report this to the snapd project.

You can provide them our snapcraft.yaml (which aligns with their documentation): https://github.com/keepassxreboot/keepassxc/blob/develop/snap/snapcraft.yaml

[crcarson]

Running Ubuntu 22.04 with Snap keepassxc 2.7.0. Find that most all operations fail, nothing happens when you select a new DB or a web site. Appears that the links in /home/[user]/snap/keepassxc/common/.cache/gio-modules are broken. They point to prior non-existent release I think.

[droidmonkey]

Can you clear out that .cache and try again?

[TomBaxter]

I cleared it out and it didn't help. Here are the files that were there.

tkb@sisyphus:~/snap/keepassxc$ ls -l common/.cache/gio-modules/ total 20 -rw-rw-r-- 1 tkb tkb 150 Dec 24 18:32 giomodule.cache lrwxrwxrwx 1 tkb tkb 77 Dec 24 18:32 libdconfsettings.so -> /snap/keepassxc/1522/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so lrwxrwxrwx 1 tkb tkb 77 Dec 24 18:32 libgiognomeproxy.so -> /snap/keepassxc/1522/usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so lrwxrwxrwx 1 tkb tkb 73 Dec 24 18:32 libgiognutls.so -> /snap/keepassxc/1522/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so lrwxrwxrwx 1 tkb tkb 75 Dec 24 18:32 libgiolibproxy.so -> /snap/keepassxc/1522/usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so

I went to update the links but the files that are linked to don't exist in the latest snap.

[TomBaxter]

I looked at the snap site again. The contact info just sends me back to this GitHub repo.

[droidmonkey]

Can you try installing keepassxc using classic confinement?

sudo snap install keepassxc --classic you might have to remove it first.

[TomBaxter]

Yes. I uninstalled and then reinstalled regular. Then uninstalled and reinstalled with --classic. Bug persists.

I looked at bug reports on the canonical snapd repo. Didn't seem to be any recent related bug reports. That said, it's not the easiest place to find and report bugs.

[droidmonkey]

This is a curious case, I can definitely say this is NOT a bug in KeePassXC. This is either a bug in core20 or kde-frameworks-5-qt-5-15-3-core20 or xdg-desktop-portal.

As you can see above, the issue occurs deep in Qt/glib code. Basically we ask for a file open dialog, but nothing is ever created/shown to the user.

[droidmonkey]

My plea for help: https://forum.snapcraft.io/t/file-chooser-doesnt-show-using-kde-neon-extension/29244

[ovals12]

@ovals12 what is your exact environment? Ubuntu version XX.XX and desktop env (KDE/GNOME/XFCE)

It is Ubuntu 21.10 (Gnome).

[fcostin]

Here is a workaround that may temporarily resolve the problem for anyone using the snap distribution of keepassxc that was auto updated (auto refreshed) from the old stable version 2.6.6 to the new stable version 2.7.0 with this issue:

tell snap to revert the installed version of keepassxc snap package to the previous stable version:

sudo snap revert keepassxc

this should succeed and display something like:

keepassxc reverted to 2.6.6

when i did this workaround, the old snap package of keepassxc 2.6.6 could launch normally and open my password database as usual.

BEWARE: this workaround ONLY works on machines where you have upgraded from a previous keepassxc 2.6.6 snap package installation, and ONLY if you have NOT uninstalled keepassxc. If you experience this "Cannot open a database on Linux" issue with a fresh install of keepassxc 2.7.0 or after uninstalling keepassxc, it will not be possible to revert to 2.6.6. There appears to be no way to install the old version keepassxc 2.6.6 through snap, but you can revert to that version if you previously had it installed on your machine.

[VasilisManol]

Same problem on Ubuntu 22.04, running keepassxc 2.7.1 from snap. Opening the db from the terminal works.

[droidmonkey]

We recommend to stop using the snap and instead switch to our flatpak or appimage. No further effort will be made to fix this problem as it is 100% on the snap side and they cannot isolate the issue or help me debug it after several attempts with them.

[JGCarroll]

Assuming you're still willing to reconsider snaps, you can partially fix the problem. Please note I've only had a little bit of time to diagnose on my lunch break, and I've 0 experience with QT.

GTK checks the environment variable GTK_USE_PORTAL to decide whether to use the XDG portals. It clearly isn't the case for QT, as checking the environment it's never set and unsetting it doesn't appear to help.

I've had zero time to look at the QT/KDE source, but taking a guess, I unset the $SNAP variable prior to launching KeepassXC, QT actually avoided using the portals falling back to the native QT file picker. It isn't perfect because of theming and being limited to $HOME in the sandbox, but it's certainly an improvement on not doing anything.

You can test the behaviour like such:

snap run --shell keepassxc
unset SNAP
keepassxc

To make this automatic to clients, you'd unfortunately have to make a Bash wrapper in the snap similar to:

#!/bin/bash
unset SNAP
keepassxc

I'd be willing to submit a PR for that later if you like.

I appreciate that that's just a stopgap measure, and that experience may have left a sour taste in your mouth, but having been just a random guy in the Snapcraft community for a while now, I'd hope that it isn't that there wasn't a desire to help, but that people's experiences and other commitments make things difficult at times.

[TomBaxter]

@VasilisManol @droidmonkey I just bumped up to 22.04 as well. There is a minor issue with FlatPak on 22.04. Ubuntu 22.04 now requires libfuse3 and doesn't come with libfuse2 by default. FlatPak requires libfuse2. I have had success installing libfuse2 along side libfuse3. But be careful. If you install the fuse package, as opposed to the fuse3 package that is already installed, it will remove libfuse3 and several packages you might be fond of. So, just install "sudo apt-get install libfuse2"

[droidmonkey]

@MrCarroll that probably invalidates the entire reason for running as a snap (ie invalidates the sandbox). So no, that is absolutely NOT recommended.

We are literally doing exactly what the documentation says to do to use the kde integration which provides an updated Qt and portal integration. I've tested multiple workarounds and debugging clues for hours. It is not worth my time to diagnose their faults. My debugging shows we properly ask for file chooser to the xdg-desktop-portal through Qt and then the portal fails to open the file chooser.

@TomBaxter sounds like a ticket for flatpak devs to resolve.

[JGCarroll]

It doesn't invalidate the sandbox, it removes exclusively the $SNAP variable, which only exists as a pointer to the snap's data (I.E, /snap/keepassxc/$revision/.

It's merely a design implementation that QT happens to check for this variable to decide whether to use the portals or not. By the time you're unsetting this variable, the entire sandbox is already functional, you won't be given any more privilege than you usually have.

Edit: responding to the above edits,

My debugging shows we properly ask for file chooser to the xdg-desktop-portal through Qt and then the portal fails to open the file chooser.

Yes, it looks to me like you're doing nothing wrong on the KeepassXC side. And I do understand the frustration of doing nothing wrong with these API's and getting unexpected results, they've bitten me personally in the past too. So there's definitely improvements that can be made on the kde-neon extensions side, but I can't guarantee any progress there because I don't understand the QT/KDE specific elements. I'll try to, because I'm a happy KeepassXC user and keen to help you guys out for your hardwork, but personally I'd encourage considering the stopgap for now and full resolution later, if you were happy to.

[TomBaxter]

@droidmonkey Agreed. It is. And they are aware of it. But doesn't sound like it will get fixed soon.

FYI. AppImage has the same trouble on Ubuntu 22.04.

[JGCarroll]

I've found the issue. The prctl() call in src/core/Bootstrap.cpp causes the files in /proc/[pid]/ to become owned by root, preventing the portals from using this folder to inspect the sandbox internals.

Assuming there's still a desire for it, I'd propose:

1) Patching out this function call if the $SNAP variable is detected (or however else might be suitable, since I think KeepassXC does have some flags somewhere that could be more specific). 2) Removing the home interface from snapcraft.yaml, since the portals would deprecate it.

Please let me know if you'd like a PR to implement the above.

[droidmonkey]

Now that's a finding! We need the home plug, so we will have to patch out the prctl call if built as a snap. We have a build flag for snap detection.

[droidmonkey]

This is now fixed and released to the snap store.

[fcostin]

i was experiencing this issue earlier, and i can i confirm the snap distribution stable/2.7.1 is able to successfully open existing databases. (OS: Ubuntu 21.10)

great detective work @MrCarroll & thank you very much @droidmonkey for shipping the patch

i am unfamiliar with prctl, i see it is used in Bootstrap.cpp to mark the process as not dumpable:

https://github.com/keepassxreboot/keepassxc/blob/9b2b861a2af451eb160c3771db6453deb90cf792/src/core/Bootstrap.cpp#L93

the man page for prctl(2) discusses PR_SET_DUMPABLE:

Set the state of the "dumpable" attribute, which determines whether core dumps are produced for the calling process upon delivery of a signal whose default behavior is to produce a core dump. [...] Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH; see ptrace(2) for further details. If a process is not dumpable, the ownership of files in the process's /proc/[pid] directory is affected as described in proc(5).

the documentation for proc(5) goes on to explain

The files inside each /proc/[pid] directory are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1.

I suppose, all things equal, we'd prefer to mark the process as not dumpable for security reasons, to make it harder for some other process to attach and recover secrets. But then doing that changes the ownership of stuff inside/proc/[pid] to increase security, and breaks how the portals expect to integrate ( ? )

[l0f4r0]

Glad to read everything that has been investigated and adjusted :)

However, it doesn't seem to work any better on my machine with 2.7.1 snap, I still cannot open a database from the GUI.

KeePassXC - Version 2.7.1 Révision : 5916a8f Distribution : Snap Qt 5.15.3 Operating System: Linux Debian 10 64bits Desktop Env: XFCE 4.12.5 Windowing System: X11

[JGCarroll]

However, it doesn't seem to work any better on my machine with 2.7.1 snap, I still cannot open a database from the GUI.

Can you try sudo apt install xdg-desktop-portal-gtk

[VasilisManol]

Nice! Works fine on my Ubuntu 22.04.

[l0f4r0]

However, it doesn't seem to work any better on my machine with 2.7.1 snap, I still cannot open a database from the GUI.

Can you try sudo apt install xdg-desktop-portal-gtk

It's already installed:

$ dpkg -l | grep -i "xdg-desktop-portal-gtk"
ii  xdg-desktop-portal-gtk                 1.2.0-1                                 amd64        GTK+/GNOME portal backend for xdg-desktop-portal

[elcste]

@l0f4r0 Just to make sure, what's your output from snap list keepassxc?

[l0f4r0]

@l0f4r0 Just to make sure, what's your output from snap list keepassxc?

$ snap list keepassxc
Name       Version  Rev   Tracking       Publisher       Notes
keepassxc  2.7.1    1563  latest/stable  keepassxreboot  -

[JGCarroll]

Can you confirm it still persists with the output from snap list keepassxc as above? There's a chance that between the information earlier and the information now, the snap has done an automatic update. (It update loop is about every 24 hours, so even if your client was abolutely on the ball with the 24 hour cycle, there's a 50% chance it wasn't updated earlier but might happen to be now, and less theoretically, rollouts only get to about 90% after about a week in my own experiences).

Assuming it does still have the error, please run dbus-monitor in the terminal, click the "open database" button in KXC, and please provide us the output, we're looking for anything that may be going wrong with the desktop portals, so hopefully there'd be hints in there.

[l0f4r0]

Whaouh, it works now!

Despite your explanation, I didn't understand why it's ok now as my client was already displaying 2.7.1 yesterday in the "About" section:

KeePassXC - Version 2.7.1 Révision : 5916a8f Distribution : Snap

Can you detail again what might have happened please?

[JGCarroll]

Both revisions identify as version 2.7.1 (at the snap metadata level and on the about screen), but you were testing the unpatched version originally until the automatic update mechanism moved you to the latest revision later.

[jaylinski]

Also works for me now on Ubuntu 20.04 (but I had to do a sudo snap remove keepassxc and sudo snap install keepassxc in order for it to work again).

[CaliforniaMountainSnake]

I cannot save attachments that were previously added to the record. The file picker dialog is just freezed. I have to kill the keepassxc process. I am using keepassxc 2.7.1 installed from snap. Version 2.6.6 saves attachments as expected.

[droidmonkey]

Attachments are updated directly in 2.7.0 when you open them. Just make the change and save the file as usual. A dialog will appear asking if you want to save the updated attachment. You are probably stuck at that dialog asking for your answer.

[tehmasterer]

I can't open or save attachments with KeePassXC 2.7.1 Snap on Ubuntu 20.04.4. No issue with this on 22.04.

• When trying to open attachment, nothing happens.
• When trying to save an attachment in ~/Downloads or anywhere else, I get Unable to save attachments: id_my_ssh_key - Not a directory

No issues with opening or saving on the Flatpak version on the same system running 20.0.4.4.

[michaelk83]

@tehmasterer, run snap refresh. https://github.com/keepassxreboot/keepassxc/issues/7607#issuecomment-1110646224

[tehmasterer]

@michaelk83 That made no difference. The snap package was already up-to-date. I also uninstalled and reinstalled it. No change.

[JGCarroll]

sudo apt install xdg-desktop-portal-gnome

or

sudo apt install xdg-desktop-portal-gtk

or

sudo apt install xdg-desktop-portal-kde

As is appropriate for your DE.

(You might need to reboot for these to actually have an effect)