On Fri, 04 Jun 2021 14:35:47 +0200 "Thomas Schmitt" <scdbac...@gmx.net> wrote:
> Hi, > > songbird wrote: > > some strange fs entry shows up: > > # ls -l /run/user/1000 > > d????????? ? ? ? ? ? doc > > We had this topic a few day ago. > https://lists.debian.org/debian-user/2021/06/msg00020.html > > I had some further private conversation with the OP John Conover which > causes me to summarize the problem like this: > > xdg-document-portal from package xdg-desktop-portal creates a FUSE > mount point as "portal" for offering selected files to the user with > the giveni id number (here: 1000). > > https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Documents > states > "The document portal allows to make files from the outside world > available to sandboxed applications in a controlled way. > Exported files will be made accessible to the application via a fuse > filesystem that gets mounted at /run/user/$UID/doc/." > > Control is obviously to be done via systemd means. Probably by > /usr/lib/systemd/user/xdg-document-portal.service > as mentioned in > https://packages.debian.org/buster/amd64/xdg-desktop-portal/filelist > > It is the normal behavior of a FUSE mount point to deny any access to > any other user including the superuser. See > https://github.com/libfuse/libfuse > "Security implications" > which says > "No other user (including root) can access the contents of the > mounted filesystem (though this can be relaxed by allowing the use of > the allow_other and allow_root mount options in /etc/fuse.conf)" > > Reason is probably that the kernel hands over its internal VFS calls > to the FUSE driver program in userspace, which is then able to answer > with arbitrary deception to the caller of the corresponding libc > function. An old superuser might not expect to be served by code that > did not go through kernel development scrutiny. > > Relaxing this security precaution (as mentioned in above quote) might > be a bad idea. > I would rather disable xdg-document-portal in order to redice the risk > rather than increasing it. A bit of followup on this. I agree with Thomas that this is an increase in security risk. Most (all?) malware detectors that scan the entire computer run as root. E.g: chkrootkit. Second, there is more to disabling this nonsense. As the relevant user, run systemctl --user stop xdg-document-portal.service systemctl --user disable xdg-document-portal.service The disable line prevents the service from being started at reboot. Third, on March 1, I installed Bullseye on a laptop. That machine did not exhibit this problem. Perhaps the difference is in a more recent version of libfuse. The machines that exhibit the problem have: root@jhegaala:~# pre fuse fuse 2.9.9-5 amd64 libfuse2 2.9.9-5 amd64 root@jhegaala:~# While the laptop that does not has: root@ideapc:~# pre fuse fuse3 3.10.3-2 amd64 libfuse2 2.9.9-5 amd64 libfuse3-3 3.10.3-2 amd64 root@ideapc:~# Or perhaps not. On the latter machine, /run/user/1000/ is present, but there is no directory doc in it: root@ideapc:~# ll /run/user/1000/ total 4 drwx------ 11 charles charles 280 Apr 16 16:42 ./ drwxr-xr-x 6 root root 120 Apr 20 02:35 ../ srw-rw-rw- 1 charles charles 0 Apr 16 10:26 bus= drwx------ 3 charles charles 60 Apr 16 10:26 dbus-1/ drwx------ 2 charles charles 60 Apr 16 10:26 dconf/ drwx------ 2 charles charles 60 Apr 16 14:20 emacs/ drwx------ 2 charles charles 140 Apr 16 10:26 gnupg/ drwx------ 2 charles charles 40 Apr 16 10:26 gvfs/ -rw------- 1 charles charles 318 Apr 16 10:26 ICEauthority drwx------ 2 charles charles 60 Apr 16 10:26 keyring/ drwxr-xr-x 2 charles charles 60 Apr 16 10:26 Nextcloud/ srw-rw-rw- 1 charles charles 0 Apr 16 10:26 pk-debconf-socket= drwx------ 2 charles charles 100 Apr 19 11:31 pulse/ drwxr-xr-x 5 charles charles 140 Apr 16 10:26 systemd/ root@ideapc:~# As I have what I want (the service disabled), I have not experimented further. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
