Re: what program sets up /run/user/1000/ ?
On Fri, 04 Jun 2021 14:35:47 +0200
"Thomas Schmitt" <scdbackup@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/
Reply to: