File chooser doesn't show using kde-neon extension

Igor · March 24, 2022, 12:35pm

I encountered the same problem on Kubuntu 18.04.

The backend error shows in the system logs was:

Can't open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files

I resolved the problem by installing xdg-desktop-portal from the system repos.

We need to think of a comprehensive solution going forward.

droidmonkey · March 25, 2022, 1:50am

I verified that xdg-desktop-portal was installed on the system, so that isn’t the problem we are facing unfortunately.

sergiusens · March 25, 2022, 2:14pm

It is not, it does not work for me on Ubuntu 22.04, but all the KDE neon using snaps I tried do, even okular which has complications on kubuntu.

droidmonkey · March 25, 2022, 7:14pm

Do you mind sharing an example project yaml using the core20 sdk?

droidmonkey · March 25, 2022, 11:05pm

Now I’m also getting users with this error:

ERROR: not connected to the kde-frameworks-5-qt-5-15-3-core20 content interface.

This appears to occur when the snap auto updates on some machines. A complete uninstall reinstall fixes it.

droidmonkey · March 27, 2022, 8:34pm

I still have not figured out how to get this to work. Anyone have any ideas on what to try?

sergiusens · March 28, 2022, 11:33am

Maybe https://snapcraft.io/umbrello (candidate has the latest content snap from kde, stable the previous one)

With the snapcraft.yaml on https://invent.kde.org/packaging/snapcraft-kde-applications/-/blob/Neon/release/umbrello/snapcraft.yaml

All kde published applications are on https://invent.kde.org/packaging/snapcraft-kde-applications

elcste · March 28, 2022, 4:01pm

I think @jriddell does a lot with KDE’s snaps. I wonder if he could take a look?

DeanSchrieffer · March 30, 2022, 10:40am

Same problem here. I am on Backbox Linux 7 which is based on Ubuntu 20.04. Version 2.6.6 worked just fine on snap, however after updating to the latest version, I encountered this problem.

KeePassXC - Version 2.7.0 Revision: 20c9ac1 Distribution: Snap Qt 5.15.3 Debugging mode is disabled. Operating system: Ubuntu Core 20 CPU architecture: x86_64 Kernel: linux 5.4.0-105-generic

ilya-fedin · April 11, 2022, 10:45am

You also need a backend (xdg-desktop-portal-gtk/xdg-desktop-portal-kde)

droidmonkey · April 11, 2022, 11:36pm

Any other ideas? This is on 21.10 live boot CD, nothing but keepassxc installed after boot.

ilya-fedin · April 11, 2022, 11:50pm

Check D-Bus messages between the application and xdg-desktop-portal with Bustle

droidmonkey · April 12, 2022, 1:23am

Same error as reported above:

The same problem with 22.04 live boot.

James-Carroll · April 25, 2022, 3:23pm

Looking into this issue, it seems to come down to the fact that the folder /run/$PID/root isn’t being correctly mounted. In every other snap I’ve tested locally, this shows the view of the containers mount namespace. However for KeepassXC for whatever reason, this link is never created.

I’d expect, the XDG portals are using this to try bridge the gap between host environment and snap environment and erroring out as a result. Is there anyone on the snapd team who could evaluate this under that light?

Having looked at the DBus messages being produced from KeepassXC, there aren’t any problems there.

Edit: /var/[PID]/root is not “missing”, it’s just only readable by root, unlike the other snaps.

James-Carroll · April 25, 2022, 8:24pm

Copying my findings from the Github issue associated to this:

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:

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).
Removing the home interface from snapcraft.yaml, since the portals would deprecate it.

droidmonkey · April 26, 2022, 1:38am

Confirmed this fixes the problem. Unfortunately that also leaves our program somewhat vulnerable since we cannot disable core dumps. It is interesting that this only impacts Ubuntu 21.10 and above.

I also confirmed it is not sufficient to just remove the home plug. That does not solve the problem.

elcste · April 26, 2022, 3:03pm

@James-Carroll How do we buy you a beer (or equivalent)?

James-Carroll · April 26, 2022, 6:35pm

The appreciation is rewarding enough, but thanks for the offer

kenvandine · April 28, 2022, 4:45pm

@jamesh do you have any insight here?

jamesh · May 3, 2022, 11:36am

Playing around with this, I think this could be fixed with an xdg-desktop-portal change.

The xdp_get_app_info_from_pid function performs a number of checks to try to determine the confinement of the calling process: first whether it is a flatpak, then a snap, then unconfined.

The flatpak check is done by trying to open /proc/$pid/root, which fails with EACCES (permission denied) after PR_SET_DUMPABLE is set to 0. It the root file system happens to be a FUSE file system, it treats this as a soft error, and it’ll continue on to check if it is a snap. Otherwise, it will be treated as a hard error and it won’t try any of the other confinement options.

If we changed it to always treat EACCES as a soft error, I think the snap confinement check would work as the /proc/$pid/cgroup and /proc/$pid/attr/current files that are used by the snap check are still readable for undumpable processes.

I’d have to think a bit more about whether there are other ramifications for this change: could a flatpak avoid detection, for instance?

In the short term, not setting the process to undumpable should fix interaction with existing xdg-desktop-portal installs. That of course removes the protections the app wanted though, so is not ideal either.