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. Have a nice day :) Thomas
