is root realy root ?

[old sixpack13]

on F37:

ls -lR /root/.cache
/root/.cache:
total 0
dr-x------. 2 root root 0  1. Jan 1970  doc

/root/.cache/doc:
total 0
dr-x------. 2 root root 0  1. Jan 1970  by-app

/root/.cache/doc/by-app:
total 0

rm -rfv /root/.cache/doc
rm: cannot remove '/root/.cache/doc/by-app': Operation not permitted

and
chmod u+w /root/.cache/doc
chmod: changing permissions of '/root/.cache/doc': Operation not permitted

and
chown -R root:root /root/.cache
chown: changing ownership of '/root/.cache/doc/by-app': Operation not permitted
chown: changing ownership of '/root/.cache/doc': Operation not permitted

???

===
Other question:

shouldn't "rpmconf -a" fixes all left over for *.rpm* in *all* directories
?

after an update via "dnf update" the last days I saw there was a file *.rpmsave
(save ?) created under /var/lib/unbound/

sudo rpmconf -a didn't fix it, but an "dnf reinstall
unbound-libs-1.17.1-1.fc37.x86_64" today did it ...

[Jeffrey Walton]

On Sat, Jan 21, 2023 at 6:32 PM old sixpack13 <sixpack13(a)online.de&gt; wrote:
>  on F37:
>
>  ls -lR /root/.cache
>  /root/.cache:
>  total 0
>  dr-x------. 2 root root 0  1. Jan 1970  doc
>
>  /root/.cache/doc:
>  total 0
>  dr-x------. 2 root root 0  1. Jan 1970  by-app
>
>  /root/.cache/doc/by-app:
>  total 0
>
>  rm -rfv /root/.cache/doc
>  rm: cannot remove '/root/.cache/doc/by-app': Operation not permitted
>
>  and
>  chmod u+w /root/.cache/doc
>  chmod: changing permissions of '/root/.cache/doc': Operation not permitted
>
>  and
>  chown -R root:root /root/.cache
>  chown: changing ownership of '/root/.cache/doc/by-app': Operation not permitted
>  chown: changing ownership of '/root/.cache/doc': Operation not permitted
>  
It sounds like selinux. Under selinux, root is just another account to
be contained.

    ls -alZ

will show you the selinux context.

>  ===
>  Other question:
>
>  shouldn't "rpmconf -a" fixes all left over for *.rpm* in *all* directories
> ?
>
>  after an update via "dnf update" the last days I saw there was a file *.rpmsave
> (save ?) created under /var/lib/unbound/ 
It sounds like you modified unbound's config file. Then, during a
system-upgrade, you kept your version of the config file instead of
taking the maintainer's version.

>  sudo rpmconf -a didn't fix it, but an "dnf reinstall
> unbound-libs-1.17.1-1.fc37.x86_64" today did it ... 
Also see
https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-...
. It will help with post-upgrade issues.

Jeff

[old sixpack13]

>  On Sat, Jan 21, 2023 at 6:32 PM old sixpack13
> <sixpack13(a)online.de&gt; wrote:
>  
>  It sounds like selinux. Under selinux, root is just another account to
>  be contained.
>  
>      ls -alZ
>  
>  will show you the selinux context.
>   
ls -lRZ /root/.cache
/root/.cache:
total 0
dr-x------. 2 root root system_u:object_r:fusefs_t:s0 0  1. Jan 1970  doc

/root/.cache/doc:
total 0
dr-x------. 2 root root system_u:object_r:fusefs_t:s0 0  1. Jan 1970  by-app

/root/.cache/doc/by-app:
total 0


ls -laZ
total 20
dr-xr-x---. 1 root root system_u:object_r:admin_home_t:s0       154 22. Jan 00:17 .
dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0             138 15. Dez 00:48 ..
-rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0  3180 22. Jan 00:00
.bash_history
-rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0        18 23. Jul 2022 
.bash_logout
-rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       141 23. Jul 2022 
.bash_profile
-rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       429 23. Jul 2022  .bashrc
drwx------. 1 root root system_u:object_r:cache_home_t:s0         6 22. Jan 00:08 .cache
drwx------. 1 root root unconfined_u:object_r:config_home_t:s0   30 21. Jan 23:44 .config
drwx------. 1 root root unconfined_u:object_r:dbus_home_t:s0     22 17. Sep 15:40 .dbus
-rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0    20 22. Jan 00:17
.lesshst
drwx------. 1 root root unconfined_u:object_r:gconf_home_t:s0    10 10. Sep 20:15 .local

I'm completely unexperienced with selinux, but shouldn't I be able to delete
.cache cause I own the dir and have write permission ?

[Jeffrey Walton]

On Sat, Jan 21, 2023 at 6:49 PM old sixpack13 <sixpack13(a)online.de&gt; wrote:
>  > On Sat, Jan 21, 2023 at 6:32 PM old sixpack13 <sixpack13(a)online.de&gt;
> wrote:
>  >
>  > It sounds like selinux. Under selinux, root is just another account to
>  > be contained.
>  >
>  >     ls -alZ
>  >
>  > will show you the selinux context.
>  >
>
>  ls -lRZ /root/.cache
>  /root/.cache:
>  total 0
>  dr-x------. 2 root root system_u:object_r:fusefs_t:s0 0  1. Jan 1970  doc
>
>  /root/.cache/doc:
>  total 0
>  dr-x------. 2 root root system_u:object_r:fusefs_t:s0 0  1. Jan 1970  by-app
>
>  /root/.cache/doc/by-app:
>  total 0
>
>  ls -laZ
>  total 20
>  dr-xr-x---. 1 root root system_u:object_r:admin_home_t:s0       154 22. Jan 00:17 .
>  dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0             138 15. Dez 00:48 ..
>  -rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0  3180 22. Jan 00:00
> .bash_history
>  -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0        18 23. Jul 2022 
> .bash_logout
>  -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       141 23. Jul 2022 
> .bash_profile
>  -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       429 23. Jul 2022 
> .bashrc
>  drwx------. 1 root root system_u:object_r:cache_home_t:s0         6 22. Jan 00:08 .cache
>  drwx------. 1 root root unconfined_u:object_r:config_home_t:s0   30 21. Jan 23:44
> .config
>  drwx------. 1 root root unconfined_u:object_r:dbus_home_t:s0     22 17. Sep 15:40 .dbus
>  -rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0    20 22. Jan 00:17
> .lesshst
>  drwx------. 1 root root unconfined_u:object_r:gconf_home_t:s0    10 10. Sep 20:15 .local
>
>  I'm completely unexperienced with selinux, but shouldn't I be able to delete
> .cache cause I own the dir and have write permission ? 
Selinux often bytes me, too.

Try relabeling your filesystem before going further.

   sudo fixfiles -B onboot
   sudo reboot && exit

If the issue persists after the reboot, then start working on the
selinux context problem.

Jeff

[old sixpack13]

>  On Sat, Jan 21, 2023 at 6:49 PM old sixpack13
> <sixpack13(a)online.de&gt; wrote:
>  
>  Selinux often bytes me, too.
>  
>  Try relabeling your filesystem before going further.
>   
yupp, that fixed it

Thanks $ALL !

[Jon LaBadie]

On Sat, Jan 21, 2023 at 11:49:05PM -0000, old sixpack13 wrote:
> ls -laZ
> total 20
> dr-xr-x---. 1 root root system_u:object_r:admin_home_t:s0       154 22. Jan 00:17 .
> dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0             138 15. Dez 00:48 ..
> -rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0  3180 22. Jan 00:00
> .bash_history
> -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0        18 23. Jul 2022 
> .bash_logout
> -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       141 23. Jul 2022 
> .bash_profile
> -rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0       429 23. Jul 2022  .bashrc
> drwx------. 1 root root system_u:object_r:cache_home_t:s0         6 22. Jan 00:08 .cache
> drwx------. 1 root root unconfined_u:object_r:config_home_t:s0   30 21. Jan 23:44 .config
> drwx------. 1 root root unconfined_u:object_r:dbus_home_t:s0     22 17. Sep 15:40 .dbus
> -rw-------. 1 root root unconfined_u:object_r:admin_home_t:s0    20 22. Jan 00:17
> .lesshst
> drwx------. 1 root root unconfined_u:object_r:gconf_home_t:s0    10 10. Sep 20:15 .local
>
> I'm completely unexperienced with selinux, but shouldn't I be able to delete
> .cache cause I own the dir and have write permission ? 
Your idea is reasonable.  To be able to modify a file you need "w" 
permission on that file.  HOWEVER, removing a file is not considered
to be modifying THAT file.  It is modifying the directory which
contains the file.

Note that if there was another hard link to the file in a different
directory, the file is not modified  Contents remain, link count
drops.  But the containing directory is modified, it loses an entry.

You have write permission on .cache, but not on ".", the containing 
directory.  So you can modify the contents of .cache, not "."


-- 
Jon H. LaBadie                  jonfu(a)jgcomp.com

[Gordon Messmer]

On 2023-01-21 15:37, Jeffrey Walton wrote:
> > chown: changing ownership of '/root/.cache/doc':
> Operation not permitted
> >
>  It sounds like selinux. 

If the problem were SELinux, the system would report "permission denied" 
and not "operation not permitted".  You can verify this with a little 
bit of roundabout testing.  Open two terminals and start "root" sessions 
in both.

You won't be able to start a confined shell with type sshd_t if the 
system is enforcing, but you won't be able to test the behavior of the 
policy while it's permissive, so...

setenforce permissive # In the first shell
runcon system_u:system_r:sshd_t:s0-s0:c0.c1023 /bin/sh # In the second shell
setenforce enforcing # In the first shell, again
# Now, in the second shell, you can test...
sh-5.2# touch foo
sh: child setpgid (83679 to 83679): Permission denied
touch: cannot touch 'foo': Permission denied

[Jeffrey Walton]

On Sun, Jan 22, 2023 at 3:23 PM Gordon Messmer <gordon.messmer(a)gmail.com&gt; wrote:
>  On 2023-01-21 15:37, Jeffrey Walton wrote:
>  >> chown: changing ownership of '/root/.cache/doc': Operation not
> permitted
>  >>
>  > It sounds like selinux.
>
>  If the problem were SELinux, the system would report "permission denied"
>  and not "operation not permitted".  You can verify this with a little
>  bit of roundabout testing.  Open two terminals and start "root" sessions
>  in both. 
I think you are correct. When I first experienced it, I think it was
EACCES, and not EPERM.

Unfortunately for users, when selinux hijacked Posix return codes,
selinux did not document them. It looks like the same is playing out
with flatpack.

Jeff

[Jonathan Billings]

>  On Jan 22, 2023, at 15:47, Jeffrey Walton <noloader(a)gmail.com&gt;
> wrote:
>  
>  On Sun, Jan 22, 2023 at 3:23 PM Gordon Messmer <gordon.messmer(a)gmail.com&gt; wrote:
> > 
> > On 2023-01-21 15:37, Jeffrey Walton wrote:
> >>> chown: changing ownership of '/root/.cache/doc': Operation not
> permitted
> >>> 
> >> It sounds like selinux.
> > 
> > If the problem were SELinux, the system would report "permission denied"
> > and not "operation not permitted".  You can verify this with a little
> > bit of roundabout testing.  Open two terminals and start "root" sessions
> > in both.
>  
>  I think you are correct. When I first experienced it, I think it was
>  EACCES, and not EPERM.
>  
>  Unfortunately for users, when selinux hijacked Posix return codes,
>  selinux did not document them. It looks like the same is playing out
>  with flatpack. 
I agree that SELinux does often cause confusing error messages, but this flatpak XDG
portal is returning exactly the correct error code you would get any time you tried to
delete a mountpoint of any kind.

-- 
Jonathan Billings

[Tom Horsley]

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

[Jonathan Billings]

On Jan 21, 2023, at 18:55, Tom Horsley <horsley1953(a)gmail.com&gt; 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