Bug 1913358
| Summary: | df: /run/user/1000/doc: Operation not permitted | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christian Kujau <redhat> |
| Component: | coreutils | Assignee: | Kamil Dudka <kdudka> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 33 | CC: | admiller, amigadave, cviruss, jamartis, jarodwilson, kdudka, kzak, okrh, ooprala, ovasik, p, sebastian.kisela, svashisht |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-06-11 01:14:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1969317 | ||
|
Description
Christian Kujau
2021-01-06 15:05:43 UTC
Reassigning to coreutils as per the Launchpad bug. 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...
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. (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 (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? (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. The Ubuntu patch is now being reviewed by gnulib upstream:
https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00054.html
I have proposed a smaller patch upstream:
https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00023.html
upstream commit: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=9a38d499ca16f2f4304992eb1ab0894cd0b478e1 Fedora commits: https://src.fedoraproject.org/rpms/coreutils/c/a0cb772e6fba19e3fdbb4dee02d78fc6b8d20d03?branch=rawhide https://src.fedoraproject.org/rpms/coreutils/c/e3fe7ff6cc7f6aa10f1650501c76232325488b7b?branch=f34 https://src.fedoraproject.org/rpms/coreutils/c/2373b34bacc1676fafe5dcaeabb92e04ec77d0f1?branch=f33 FEDORA-2021-e811b9be31 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e811b9be31 FEDORA-2021-01c16188fe has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-01c16188fe 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. 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. 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. 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. Bug persists with coreutils.x86_64 8.32-30.fc34 Could you please provide steps to reproduce? 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 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. 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. 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. 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? 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. 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. 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 |