Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

what program sets up /run/user/1000/ ?

963 views
Skip to first unread message

songbird

unread,
Jun 4, 2021, 8:00:04 AM6/4/21
to

some strange fs entry shows up:

# ls -l /run/user/1000
ls: cannot access '/run/user/1000/doc': Permission denied
total 4
srw-rw-rw- 1 frog frog 0 Jun 4 07:06 bus
drwx------ 3 frog frog 60 Jun 4 07:06 dbus-1
drwx------ 2 frog frog 60 Jun 4 07:06 dconf
d????????? ? ? ? ? ? doc
drwx------ 2 frog frog 140 Jun 4 07:06 gnupg
drwx------ 2 frog frog 40 Jun 4 07:06 gvfs
-rw------- 1 frog frog 306 Jun 4 07:06 ICEauthority
drwx------ 2 frog frog 100 Jun 4 07:06 keyring
srw-rw-rw- 1 frog frog 0 Jun 4 07:06 pipewire-0
-rw-r----- 1 frog frog 0 Jun 4 07:06 pipewire-0.lock
drwx------ 2 frog frog 80 Jun 4 07:06 pulse
drwxr-xr-x 5 frog frog 140 Jun 4 07:06 systemd


# checkrestart
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
Output information may be incomplete.
Found 3 processes using old versions of upgraded files
(1 distinct program)
(1 distinct packages)
These processes (1) do not seem to have an associated init script to restart them:
...

thanks! :)


songbird

Greg Wooledge

unread,
Jun 4, 2021, 8:10:04 AM6/4/21
to
On Fri, Jun 04, 2021 at 07:38:46AM -0400, songbird wrote:
> # ls -l /run/user/1000
> ls: cannot access '/run/user/1000/doc': Permission denied
> total 4
> srw-rw-rw- 1 frog frog 0 Jun 4 07:06 bus
> drwx------ 3 frog frog 60 Jun 4 07:06 dbus-1
> drwx------ 2 frog frog 60 Jun 4 07:06 dconf
> d????????? ? ? ? ? ? doc

Didn't we *just* have this exact same discussion?

At least you showed the shell prompt and the command that you ran,
which is a huge improvement over the previous iteration, where we
were left guessing at *so* many things. Thank you for that.

In your case, because you were competent enough to show the shell prompt
along with your command, we know that you ran this ls as *root*, not
as user 1000. That's why you can't see it. Only user 1000 can see it.

Here's (the start of) the previous discussion thread:
<https://lists.debian.org/debian-user/2021/06/msg00020.html>

Thomas Schmitt

unread,
Jun 4, 2021, 8:40:05 AM6/4/21
to
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

Polyna-Maude Racicot-Summerside

unread,
Jun 4, 2021, 8:40:05 AM6/4/21
to
Hi,
Thanks for this nice message.
That's a great proof that some people with knowledge (and smart) do run
GNOME.

--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development

OpenPGP_signature

Thomas Schmitt

unread,
Jun 4, 2021, 8:40:05 AM6/4/21
to
Hi,

i wrote:
> I would rather disable xdg-document-portal in order to redice the risk
> rather than increasing it.

I meant "reduce" rather than "redice".
(But mathematically it is a quite appropriate typo while talking about
unknown risks. It's a gamble.)

Thomas Schmitt

unread,
Jun 4, 2021, 8:50:04 AM6/4/21
to
Hi,

Polyna-Maude Racicot-Summerside wrote:
> That's a great proof that some people with knowledge (and smart) do run
> GNOME.

Actually i run fvwm2 and don't even know how to get an xterm from the
GNOME ridden Ubuntu VM which i have to start once in a year.

The presented knowledge stems from a scary ride through the googleverse
and over the package mountains of Debian.

songbird

unread,
Jun 4, 2021, 9:20:04 AM6/4/21
to
Thomas Schmitt wrote:
...
> Have a nice day :)

thanks! sorry all, did not see the topic already went by.


songbird

songbird

unread,
Jun 4, 2021, 9:30:05 AM6/4/21
to
haha! :) cheers!


songbird

Charles Curley

unread,
Apr 20, 2022, 10:20:05 AM4/20/22
to
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/
0 new messages