Re: is root realy root ?
On Jan 21, 2023, at 18:55, Tom Horsley <horsley1953(a)gmail.com> wrote:
On Sat, 21 Jan 2023 23:31:43 -0000
old sixpack13 wrote:
> rm -rfv /root/.cache/doc
> rm: cannot remove '/root/.cache/doc/by-app': Operation not permitted
That is (if I recall) an annoying fuse or special device file of some
kind created by some annoying xdg or gnome something that I spent a long
time figuring out how to disable specifically because it caused rsync
errors in backups making me think there was a backup problem. Whatever
purpose it serves is something I don't use because I've never had
a problem after eradicating it. I've currently got all these "user"
services masked, I think it was one of them (probably the document
portal thing).
flatpak-oci-authenticator.service
flatpak-portal.service
flatpak-session-helper.service
tracker-xdg-portal-3.service
xdg-desktop-portal-gtk.service
xdg-desktop-portal.service
xdg-document-portal.service
The existence of a /root/.cache/doc fuse mount is because the xdg-document-portal service
ran (maybe because a flatpak was run as root?) and there was no XDG_RUNTIME_DIR (which
would be /run/user/0/ when a full session is run). In the absence of a runtime dir, the
portals use XDG_CACHE_HOME, which is ~/.cache. Obviously, no one should be logging in with
a full dbus session with root, so it is weird that root got this mountpoint.
It isn’t an SELinux issue, you are just trying to delete a mountpoint with rm, which is
not permitted. If it happens again, check /proc/self/mounts to see if it is a mountpoint.
This isn’t something special about fuse mounts, if you tried to delete the directory where
a local or remote filesystem was mounted, it would generate the same error, even as root.
Turning off and disabling the xdg-desktop services for all users will cause more problems
down the road if you want to have a sandboxed flatpak app running as a normal user. Don’t
recommend it.
You should figure out why the root user was trying to set up a flatpak sandbox or whatever
else is triggering the desktop portal as root. A reboot will fix it too, since the XDG
services aren’t automatically started for root.
--
Jonathan Billings