1

I have a basic understanding on file system permissions in Linux (or I thougth I have so far...), but what I'm facing right now is confusing for me.

To double check it and for demonstration, I've re-created it on a clear OEL installation.

I have 3 users: root, svcuser (member of the "mygroup" group) and otheruser

[root@oel ~]# id root
uid=0(root) gid=0(root) groups=0(root)
[root@oel ~]# id svcuser
uid=500(svcuser) gid=501(svcuser) groups=501(svcuser),500(mygroup)
[root@oel ~]# id otheruser
uid=501(otheruser) gid=502(otheruser) groups=502(otheruser)

There is a folder ("app") in /opt, and a subfoler in it ("sub"). /opt is owned by root:root, just like /opt/app, but /opt/app/sub is owned by svcuser:mygroup, permissions set to 700, but as root, I'm still able to list its contents and create a new file in it:

[root@oel ~]# cd /opt
[root@oel opt]# ll
total 8
drwxr-xr-x. 3 root root 4096 Aug 30 23:24 app
drwxr-xr-x. 2 root root 4096 Mar 26  2015 rh
[root@oel opt]# ll app
total 4
drwx------. 2 svcuser mygroup 4096 Aug 30 23:27 sub
[root@oel opt]# ll app/sub
total 0
-rw-r--r--. 1 root root 0 Aug 30 23:27 newfile

I can't do the same as "otheruser".

There is no default ACL inherited:

[root@oel ~]# getfacl /opt/app
getfacl: Removing leading '/' from absolute path names
# file: opt/app
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

[root@oel ~]# getfacl /opt/app/sub/
getfacl: Removing leading '/' from absolute path names
# file: opt/app/sub/
# owner: svcuser
# group: mygroup
user::rwx
group::---
other::---

What is the reason for this behaviour? Does the root user have any additional privilege for accessing such folders, without being explicitly having the permissions for it? Or is it because of the parent folder being owned by root?

I've checked the SELinux settings as well, but as far as I understand, they only come into play when DAC rules does not deny access already, which is the case I think, but "root" and "otheruser" have the same context, so this should not make a difference:

[root@oel opt]# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@oel ~]# su otheruser
[otheruser@oel root]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[root@oel opt]# ls -Z
drwxr-xr-x. root root unconfined_u:object_r:usr_t:s0   app
drwxr-xr-x. root root system_u:object_r:usr_t:s0       rh
[root@oel opt]# ls -Z app/
drwx------. svcuser mygroup unconfined_u:object_r:usr_t:s0   sub

Because of the parent folder being owned by root-thing, I've tried to do the same with subfolders under the home folders of both users: the same happens with root, but with "otheruser", I can't even chown to someone else.

[root@oel ~]# pwd
/root
[root@oel ~]# ll
total 48
-rw-------. 1 root    root     1829 May  6 16:20 anaconda-ks.cfg
-rw-r--r--. 1 root    root    28275 May  6 16:20 install.log
-rw-r--r--. 1 root    root     7570 May  6 16:17 install.log.syslog
drwxr-xr-x. 2 svcuser mygroup  4096 Aug 30 23:32 sub

To be honest, now I totally lost track, so basically my question would be, what is this exactly I'm missing? I've spent the day looking at questions on Linux file permissions, but I've seen only really basic use cases, and I can't really understand this. Are some privileges inherited from the parent folders resulting in this?

  • 3
    See this U&L question. – Kamil Maciorowski Aug 30 '18 at 22:20
  • If you're basically asking if root has file/folder permissions without explicitly being granted them, the answer is yes. That's why it's referred to as the superuser. Think of it as having something akin to god mode. – n8te Aug 30 '18 at 22:34
  • Basically, permissions concept doesn't applied to root (except file execution permission) – Alex Aug 31 '18 at 1:35
  • Thanks, just one thing I don't understand now: I checked on a production server, where my home foulder has the same permissions set, but when attempting to list its content with the root user, I'm still getting a permission denied error. My home fould is mounted via NFS. If the root user overrides permissions checks, how can this be achieved? – jumpUpToTheCeiling Sep 3 '18 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.