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.
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.
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.
