File chooser doesn't show using kde-neon extension

snapcraft
#22

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:

  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.
4 Likes
#23

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.

#24

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

3 Likes
#25

The appreciation is rewarding enough, but thanks for the offer :slight_smile:

5 Likes
#26

@jamesh do you have any insight here?

#27

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.

2 Likes