Permissões do sistema de arquivos Linux como usuário root e não-root?

1

Eu tenho uma compreensão básica sobre as permissões do sistema de arquivos no Linux (ou até agora eu tenho até agora ...), mas o que estou enfrentando agora é confuso para mim.

Para verificar novamente e para demonstração, recriou-o em uma instalação clara de OEL.

Eu tenho 3 usuários: root, svcuser (membro do grupo "mygroup") e 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)

Existe uma pasta ("app") em / opt e um subfoliador nela ("sub"). / opt é de propriedade root: root, assim como / opt / app, mas / opt / app / sub é de propriedade de svcuser: mygroup, permissões configuradas para 700, mas como root, eu ainda posso listar seu conteúdo e criar um novo arquivo nele:

[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

Eu não posso fazer o mesmo que "otheruser".

Não há nenhuma ACL padrão herdada:

[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::---

Qual é o motivo para esse comportamento? O usuário root tem algum privilégio adicional para acessar essas pastas, sem ter explicitamente as permissões para isso? Ou é por causa da pasta pai pertencente ao root?

Eu também verifiquei as configurações do SELinux, mas pelo que entendi, elas só entram em jogo quando as regras do DAC já não negam acesso, o que é o caso, mas "root" e "otheruser" no mesmo contexto, então isso não deve fazer diferença:

[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

Por causa da pasta pai pertencente ao root-thing, eu tentei fazer o mesmo com as subpastas nas pastas iniciais de ambos os usuários: o mesmo acontece com o root, mas com "otheruser", não consigo nem chown para outra pessoa.

[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

Para ser honesto, agora eu perdi totalmente a noção, então basicamente minha pergunta seria: o que exatamente isso está faltando? Passei o dia examinando questões sobre permissões de arquivos do Linux, mas só vi casos de uso realmente básicos e não consigo entender isso. Alguns privilégios são herdados das pastas pai, resultando nisso?

    
por jumpUpToTheCeiling 31.08.2018 / 00:16

0 respostas