Symlinking from /run/user/1000 breaks other flatpacked apps related to KeePassXC and flatpacked KeePassXC

[purejava]

Overview

With cryptomator/cryptomator#2540 it was discovered, that the symlink in /run/user/1000 invented with #8030 keeps flatpacked Cryptomator as well as flatpacked KeePassXC 2.7.4 from starting. They fail with:

bwrap: Can't make symlink at /run/user/1000/org.keepassxc.KeePassXC.BrowserServer: File exists

For a flatpacked app like Cryptomator to access the KeePassXC proxy socket file, a filesystem permission has to be set in the manifest like:

 - --filesystem=xdg-run/org.keepassxc.KeePassXC.BrowserServer 

However, flatpak run tries to create a symlink in /run/user/1000, which fails as described above.

Context

KeePassXC - 2.7.2+, installed from a packages repo or run as an AppImage.
Versions 2.7.2+ installed from flathub do not show this issue, as they do not create the symlink.

Operating System: Linux

[droidmonkey]

Why are you creating a socket? You should just point to the xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer or you need to allow access to the new location while still pointing to the old location.

[purejava]

Why are you creating a socket?

I am not. As I wrote, flatpak run creates a symlink on starting a flatpacked app that has a filesystem permission referencing the KeePassXC socket file and there is nothing I can do about the flatpak run behavior.

You should just point to the xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer or you need to allow access to the new location while still pointing to the old location.

This is right, but that fails due to the symlink you create.

[droidmonkey]

sorry made a mistake, you are running into the reason why we made this change to begin with. In your flatpak definition you need to allow access to all files under xdg-run/app/org.keepassxc.KeePassXC and then make the connection to the BrowserServer socket. Either you do this or allow access to all files within the xdg-run directory.

[purejava]

Sorry, it think, your are still mistaken. Or I do not get your point.

The problem is not, that flatpacked Cryptomator can't access the socket file.

Cryptomator already implemented the new socket file location, together with the old one:
cryptomator/flathub#3

The problem is, that Cryptomator (and flatpacked KeePassXC) do not start at all with an existing symlink, created by a started not flatpacked KeePassXC 2.7.2+ before.

[droidmonkey]

Delete this line

[purejava]

If I would, flatpacked Cryptomator wouldn't be able to connect to KeePassXC prior to 2.7.2 installed from a repo or run as an AppImage.

[droidmonkey]

Then you will have to set it to: --filesystem=xdg-run there is no other option. I recommend just cutting support for versions less than 2.7.2.

[purejava]

Then you will have to set it to: --filesystem=xdg-run there is no other option. I recommend just cutting support for versions less than 2.7.2.

Your suggested setting isn't allowed:

ralph@fusion ~ % sudo flatpak override --filesystem=xdg-run org.cryptomator.Cryptomator 
Fehler: Unknown filesystem location xdg-run, valid locations are: host, host-os, host-etc, home, xdg-*[/…], ~/dir, /dir
ralph@fusion ~ % 

I understand, that you do not want to give up the symlink, even, if this breaks your own application, installed from flathub.

For Cryptomator, we do have workarounds, one of them is to use the KeePassXC from flathub as this is sandboxed as well and does not set the symlink.

[purejava]

I am reopening this, as the issue persists.

ralph@fusion ~ % flatpak --verbose run org.cryptomator.Cryptomator
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /home/ralph/.local/share/flatpak
F: Opening user flatpak installation at path /home/ralph/.local/share/flatpak
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /home/ralph/.local/share/flatpak
F: Opening system flatpak installation at path /var/lib/flatpak
F: /var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/21.08/406b52eb25141a7e144dbfdb2ad81083ded20e2d207643d425395fbcb0e6fe99/files/lib32 does not exist
F: Cleaning up unused container id 3907506952
F: Cleaning up per-app-ID state for org.cryptomator.Cryptomator
F: Cleaning up unused container id 501109527
F: Cleaning up per-app-ID state for org.cryptomator.Cryptomator
F: Allocated instance id 882039253
F: Add defaults in dir /org/cryptomator/Cryptomator/
F: Add locks in dir /org/cryptomator/Cryptomator/
F: Allowing dri access
F: Allowing homedir access
F: Allowing x11 access
F: Running 'bwrap --args 39 xdg-dbus-proxy --args=41'
F: Running 'bwrap --args 39 cryptomator'
bwrap: Can't make symlink at /run/user/1000/org.keepassxc.KeePassXC.BrowserServer: File exists
ralph@fusion ~ %

bubblewrap cat't set a symlink on second start of Cryptomator.

[ilpssun]

On Linux Mint, I can't launch Thunderbird (Flatpak) due to this. I don't quite understand whether this is a bug in keepassxc or flatpak, though.

[droidmonkey]

Thunderbird with no extensions? I definitely think this is a bwrap or flatpak bug. It shouldn't refuse to start (ie error out) due to a file already existing. That is plain dumb.

[ilpssun]

Yeah, it seems to me, too, that this should be filed in a different project: The first start of Thunderbird works (even if KeepassXC is already running), only subsequent launches do not work with KeepassXC running. My profile has no Thunderbird extensions.
(I started trying out a keepassxc integration and then deleted the extension after not being able to get it working properly with Flatpak sandbox security. I think I reverted everything I did, but maybe some remnants of configuration still exist somewhere…)

[oniGino]

Hello everone, just ran into this with a com.google.Chrome flatpak, if anyone has any manual override which resolve this, please do share them in the interim..

Thanks!

[ieugen]

In my case I have managed to make flatpak firefox + flatpak keepasxc integration work by using flatseal.

I have added Filesystem permissions to firefox app, for directories:

• /var/lib/flatpak/exports/bin
• /run/user/1000/app/org.keepassxc.KeePassXC

I think only the second one migh do it - but too lazy to check.
If someone knows how to do that via CLI, please test and post it.

[5310]

Hello everone, just ran into this with a com.google.Chrome flatpak, if anyone has any manual override which resolve this, please do share them in the interim..

@oniGino, did you figure out a workaround for this?

(Apologies for this tangent, but GitHub still doesn't have DMs, so I had to initiate here.)

Flatpak Chrome is still creating a symlink for PWA support, breaking a lot of things on the Steam Deck at least—like Flatpak apps not being able to open links, and xdg portals hanging, and taking the whole gamemode with it. If you now know of a way to either stop the symlink from being created or symlinks breaking Flatpak, I'd be very grateful 🙏

[oniGino]

Hello everone, just ran into this with a com.google.Chrome flatpak, if anyone has any manual override which resolve this, please do share them in the interim..

@oniGino, did you figure out a workaround for this?

(Apologies for this tangent, but GitHub still doesn't have DMs, so I had to initiate here.)

Flatpak Chrome is still creating a symlink for PWA support, breaking a lot of things on the Steam Deck at least—like Flatpak apps not being able to open links, and xdg portals hanging, and taking the whole gamemode with it. If you now know of a way to either stop the symlink from being created or symlinks breaking Flatpak, I'd be very grateful 🙏

No , I gave up on it I just manually copy things over for now. Hopefully it gets fixed one day

[5310]

No , I gave up on it I just manually copy things over for now. Hopefully it gets fixed one day

Oh well, with Manifest v3 and other stuff Chrome was already cutting it close I suppose...

Thank you for the update 😊.