Bug 1913358 - df: /run/user/1000/doc: Operation not permitted
Summary: df: /run/user/1000/doc: Operation not permitted
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1969317
TreeView+ depends on / blocked
 
Reported: 2021-01-06 15:05 UTC by Christian Kujau
Modified: 2021-09-17 10:47 UTC (History)
13 users (show)

Fixed In Version: coreutils-8.32-27.fc35 coreutils-8.32-27.fc34 coreutils-8.32-19.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-11 01:14:31 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1905623 0 None None None 2021-01-06 15:05:43 UTC

Description Christian Kujau 2021-01-06 15:05:43 UTC
Description of problem:

df(1) is exiting with a non-zero return code when run as a normal user:


$ df -h > /dev/null; echo $?
df: /run/user/1000/doc: Operation not permitted
1


Version-Release number of selected component (if applicable):


  xdg-desktop-portal-1.8.0-1.fc33.x86_64


How reproducible:

Always

Steps to Reproduce:
1. xdg-document-portal.service is running, as it is the default
2. execute df w/o for all file systems
3. RC 1

Actual results:

df: /run/user/1000/doc: Operation not permitted


Expected results:

df should exit with RC 0 and stderr should be empty.

Additional info:

This has discussed in:

> df: /run/user/1000/doc: Operation not permitted
> https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1905623

and also upstream in:

> df (and other commands) fail on /root/.cache/doc #512
> https://github.com/flatpak/xdg-desktop-portal/issues/512

The workaround is to disable (and mask) xdg-document-portal.service. However, xdg-desktop-portal cannot be uninstalled as gnome-shell depends on it for some reason.

Comment 1 David King 2021-01-06 15:18:34 UTC
Reassigning to coreutils as per the Launchpad bug.

Comment 2 Kamil Dudka 2021-01-06 17:16:39 UTC
Could you please provide the output of `df -T` with root privileges?

The Ubuntu patch does not seem to be included (or ever proposed) upstream.  As I understand it, they just extended their downstream patch:

    https://launchpadlibrarian.net/510003931/coreutils_8.32-4ubuntu1_8.32-4ubuntu2.diff.gz

I wanted to ask on the Ubuntu bug about it but was not able to get my Ubuntu account working...

Comment 3 Christian Kujau 2021-01-06 18:59:54 UTC
As root, no warning is printed, but the file system doesn't show up either:

# /bin/df -h
Filesystem              Size  Used Avail Use% Mounted on
devtmpfs                 16G     0   16G   0% /dev
tmpfs                    16G  297M   16G   2% /dev/shm
tmpfs                   6.3G   11M  6.3G   1% /run
/dev/mapper/luks--root  824G  610G  215G  74% /
/dev/nvme0n1p5          477M  211M  262M  45% /boot
/dev/nvme0n1p1          256M   60M  197M  24% /boot/efi
tmpfs                    16G   30M   16G   1% /tmp
tmpfs                   3.2G  1.9M  3.2G   1% /run/user/1000

# mount | grep portal
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)




It gets a bit weird, because I cannot access the mountpoint as root, only as the user the mount was configured for:


=========================================================================
# ls -la /run/user/1000/doc
ls: cannot access '/run/user/1000/doc': Permission denied


$ ls -lRa /run/user/1000/doc
/run/user/1000/doc:
total 0
dr-x------.  2 christian christian   0 Jan  1  1970 .
drwx------. 12 christian christian 480 Jan  6 19:05 ..
dr-x------.  2 christian christian   0 Jan  1  1970 by-app

/run/user/1000/doc/by-app:
total 0
dr-x------. 2 christian christian 0 Jan  1  1970 .
dr-x------. 2 christian christian 0 Jan  1  1970 ..
=========================================================================


Yes, the Ubuntu folks appear to have adjusted coreutils/lib/mountlist.c to exclude fuse.portal, but upstream doesn't even seem to have to have a mechanism for excluding certain filesystems from printing.

Comment 4 Kamil Dudka 2021-01-06 19:17:07 UTC
(In reply to Christian Kujau from comment #3)
> As root, no warning is printed, but the file system doesn't show up either:

Could you please try `df -aT`?

> Yes, the Ubuntu folks appear to have adjusted coreutils/lib/mountlist.c to
> exclude fuse.portal, but upstream doesn't even seem to have to have a
> mechanism for excluding certain filesystems from printing.

If the file can be changed downstream, it can be changed upstream, too.  Upstream is gnulib in this case though:

    https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/mountlist.c

Comment 5 Christian Kujau 2021-01-06 23:35:35 UTC
(In reply to Kamil Dudka from comment #4)
> Could you please try `df -aT`?


Yes, sorry, here it is, as root:


$ df -aT
Filesystem                     Type            1K-blocks      Used Available Use% Mounted on
sysfs                          sysfs                   0         0         0    - /sys
proc                           proc                    0         0         0    - /proc
devtmpfs                       devtmpfs         16356544         0  16356544   0% /dev
securityfs                     securityfs              0         0         0    - /sys/kernel/security
tmpfs                          tmpfs            16378680    316092  16062588   2% /dev/shm
devpts                         devpts                  0         0         0    - /dev/pts
tmpfs                          tmpfs             6551476     18468   6533008   1% /run
cgroup2                        cgroup2                 0         0         0    - /sys/fs/cgroup
pstore                         pstore                  0         0         0    - /sys/fs/pstore
efivarfs                       efivarfs                0         0         0    - /sys/firmware/efi/efivars
none                           bpf                     0         0         0    - /sys/fs/bpf
none                           tracefs                 0         0         0    - /sys/kernel/tracing
/dev/mapper/luks--vg0-lv--root btrfs           864014336 638839792 224428640  75% /
selinuxfs                      selinuxfs               0         0         0    - /sys/fs/selinux
systemd-1                      -                       -         -         -    - /proc/sys/fs/binfmt_misc
hugetlbfs                      hugetlbfs               0         0         0    - /dev/hugepages
mqueue                         mqueue                  0         0         0    - /dev/mqueue
debugfs                        debugfs                 0         0         0    - /sys/kernel/debug
fusectl                        fusectl                 0         0         0    - /sys/fs/fuse/connections
configfs                       configfs                0         0         0    - /sys/kernel/config
/dev/nvme0n1p5                 ext4               487634    216003    267535  45% /boot
/dev/nvme0n1p1                 vfat               262144     61112    201032  24% /boot/efi
tmpfs                          tmpfs            16378684     30984  16347700   1% /tmp
sunrpc                         rpc_pipefs              0         0         0    - /var/lib/nfs/rpc_pipefs
net_cls                        cgroup                  0         0         0    - /sys/fs/cgroup/net_cls
tmpfs                          tmpfs             3275736      1948   3273788   1% /run/user/1000
gvfsd-fuse                     fuse.gvfsd-fuse         0         0         0    - /run/user/1000/gvfs
portal                         fuse.portal             0         0         0    - /run/user/1000/doc
binfmt_misc                    binfmt_misc             0         0         0    - /proc/sys/fs/binfmt_misc



> Upstream is gnulib in this case though:


Indeed, I see it now; building coreutils-git will pull in gnulib, so something like this might^W will do the trick:


$ diff --git a/gnulib/lib/mountlist.c b/gnulib/lib/mountlist.c
index fae5b601b..bf1ed5b7d 100644
--- a/gnulib/lib/mountlist.c
+++ b/gnulib/lib/mountlist.c
@@ -164,7 +164,10 @@
 
 #define ME_DUMMY_0(Fs_name, Fs_type)            \
   (strcmp (Fs_type, "autofs") == 0              \
+   || strcmp (Fs_type, "devtmpfs") == 0                \
+   || strcmp (Fs_type, "fuse.portal") == 0     \
    || strcmp (Fs_type, "proc") == 0             \
+   || strcmp (Fs_type, "squashfs") == 0                \
    || strcmp (Fs_type, "subfs") == 0            \
    /* for Linux 2.6/3.x */                      \
    || strcmp (Fs_type, "debugfs") == 0          \




Compiled and tested, and df(1) will exit with RC 0, unless run with -a:


$ /var/tmp/df.patched -a > /dev/null 
/var/tmp/df: /run/user/1000/doc: Operation not permitted

$ /var/tmp/df > /dev/null; echo $?
0


So, maybe I should've opened the bug against gnulib instead :-)
But for some reason I noticed it only in F33 and only recently, maybe the addition (?) of fuse.portal is new in Fedora 33?

Comment 6 Kamil Dudka 2021-01-07 07:36:10 UTC
(In reply to Christian Kujau from comment #5)
> $ df -aT
> Filesystem                     Type            1K-blocks      Used Available Use% Mounted on
> [...]
> portal                         fuse.portal             0         0         0    - /run/user/1000/doc

So it is really the "fuse.portal" file system what causes us problems.

> > Upstream is gnulib in this case though:
> 
> Indeed, I see it now; building coreutils-git will pull in gnulib,

Exactly.
 
> Compiled and tested, and df(1) will exit with RC 0, unless run with -a:

Perfect, thanks for testing!

> So, maybe I should've opened the bug against gnulib instead :-)

The Fedora component is actually correct but I refuse to patch coreutils in Fedora until the fix is accepted by gnulib upstream.  I have asked on the Ubuntu bug regarding the status of upstream inclusion of the fix:

    https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1905623/comments/12

> But for some reason I noticed it only in F33 and only recently, maybe the
> addition (?) of fuse.portal is new in Fedora 33?

No idea.  I do not use gnome-shell or flatpak myself.

Comment 7 Kamil Dudka 2021-02-15 08:08:02 UTC
The Ubuntu patch is now being reviewed by gnulib upstream:

    https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00054.html

Comment 8 Kamil Dudka 2021-06-07 12:45:45 UTC
I have proposed a smaller patch upstream:

    https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00023.html

Comment 10 Fedora Update System 2021-06-08 08:11:21 UTC
FEDORA-2021-e811b9be31 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e811b9be31

Comment 11 Fedora Update System 2021-06-08 08:11:24 UTC
FEDORA-2021-01c16188fe has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-01c16188fe

Comment 12 Fedora Update System 2021-06-09 03:09:40 UTC
FEDORA-2021-01c16188fe has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-01c16188fe`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-01c16188fe

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Fedora Update System 2021-06-09 03:28:44 UTC
FEDORA-2021-e811b9be31 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e811b9be31`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e811b9be31

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2021-06-11 01:14:31 UTC
FEDORA-2021-e811b9be31 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Fedora Update System 2021-06-24 16:45:14 UTC
FEDORA-2021-01c16188fe has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 John Freed 2021-09-16 16:23:02 UTC
Bug persists with coreutils.x86_64                      8.32-30.fc34

Comment 17 Kamil Dudka 2021-09-16 20:25:02 UTC
Could you please provide steps to reproduce?

Comment 18 John Freed 2021-09-16 22:35:05 UTC
1. Install coreutils 8.32-30.fc34

2. $ df /run/user/1000/doc
df: /run/user/1000/doc: Operation not permitted

3. $ sudo df /run/user/1000/doc
df: /run/user/1000/doc: Permission denied

Comment 19 Kamil Dudka 2021-09-17 06:48:09 UTC
Thanks!  That explains it.  This bug was about running `df` without any operand.  If you explicitly run `df /run/user/1000/doc` and you are not permitted to access the file, there is nothing that coreutils could do better.

Comment 20 John Freed 2021-09-17 07:27:04 UTC
Well, the title of the bug is "df: /run/user/1000/doc: Operation not permitted", and that's still the case.

And I do in fact have permission to access the file:

$ ls -Fl1 /run/user/1000/doc
total 0
dr-x------. 2 john john 0 Jan  1  1970 by-app/

$ stat /run/user/1000/doc
  File: /run/user/1000/doc
  Size: 0         	Blocks: 0          IO Block: 4096   directory
Device: 41h/65d	Inode: 1           Links: 2
Access: (0500/dr-x------)  Uid: ( 1000/    john)   Gid: ( 1000/    john)
Context: system_u:object_r:fusefs_t:s0
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 1970-01-01 01:00:00.000000000 +0100
 Birth: -

Essentially what I think you have done is masked the particular error that was being generated in one particular case (`df` without any argument) but have not addressed the underlying problem.

I don't disagree with your statement that "there is nothing that coreutils could do better" (you're the expert), but the bug itself persists.

Comment 21 John Freed 2021-09-17 07:31:40 UTC
By comparison, here is the output from /run/user/1000/gvfs, which is also a fusefs mount:

$ df /run/user/1000/gvfs
Filesystem     1K-blocks  Used Available Use% Mounted on
gvfsd-fuse             0     0         0    - /run/user/1000/gvfs

$ stat /run/user/1000/gvfs
  File: /run/user/1000/gvfs
  Size: 0         	Blocks: 0          IO Block: 4096   directory
Device: 40h/64d	Inode: 1           Links: 2
Access: (0500/dr-x------)  Uid: ( 1000/    john)   Gid: ( 1000/    john)
Context: system_u:object_r:fusefs_t:s0
Access: 2021-09-15 07:54:38.000000000 +0200
Modify: 2021-09-15 07:54:38.000000000 +0200
Change: 2021-09-15 07:54:38.000000000 +0200
 Birth: -

So coreutils seems to handle gvfs just fine, but fails with doc.

Comment 22 Kamil Dudka 2021-09-17 08:01:46 UTC
So you might be permitted to do some operations on the file (e.g. the statx() syscall, which is sufficient for ls) but, at the same time, not permitted to do other operations (e.g. the statfs() syscall, which is used by df).  Why are you invoking `df /run/user/1000/doc` in the first place?

Comment 23 John Freed 2021-09-17 10:09:59 UTC
I was looking at a different problem in /run/user (related to DBus) and ran across this bug description. It notes, "If problem still persists, please make note of it in this bug report." So I did.

In general I don't like surprises in my filesystems, and I had not seen this one before. Adding to the mystery was the stale date (1 Jan 1970) and the fact that the directory was accessible but not modifiable.

Also in general I'm not a big fan of fixing symptoms rather than problems. If statfs works on /run/user/1000/gvfs and not /run/user/1000/doc, that indicates to me that there is an underlying problem with the creators of /run/user/1000/doc (which as I understand it from this bug report is xdg-desktop-portal).

So I suppose this bug is fixed for coreutils but continues to be a problem for xdg-desktop-portal, which in turn seems to be part of flatpak.

And I see it has been reported (under the same name) to flatpak:

https://github.com/flatpak/xdg-desktop-portal/issues/553

So it seems that the coreutils part of this is done, if I am reading you correctly. Thanks.

Comment 24 Kamil Dudka 2021-09-17 10:32:40 UTC
FUSE is not a file system on its own.  It is just an interface to implement file systems in user-space.  The particular file system implementation decides what your are permitted to access how and what not.

Comment 25 John Freed 2021-09-17 10:47:06 UTC
Ah, thanks for that. So in that case, xdg-desktop-portal should reply to a statfs() syscall with a bunch of zero values (like gvfs does) rather than an "Operation not permitted" error.

$ df /run/user/1000/gvfs
Filesystem     1K-blocks  Used Available Use% Mounted on
gvfsd-fuse             0     0         0    - /run/user/1000/gvfs


Note You need to log in before you can comment on or make changes to this bug.