Os usuários vi e rust compartilham o grupo rust e desejam usar alguns arquivos de maneira compartilhada.
rust$ ls -l myfile
-rw-rw-r-- 1 vi rust 0 May 30 03:48 myfile
rust$ stat myfile | grep Gid
Access: (0664/-rw-rw-r--) Uid: ( 1000/ vi) Gid: ( 1057/ rust)
rust$ id
uid=1048(rust) gid=1057(rust) groups=1057(rust),...
rust$ cat myfile
rust$ touch myfile
touch: cannot touch ‘myfile’: Permission denied
rust $ dd of=myfile
dd: failed to open ‘myfile’: Permission denied
vi$ id
uid=1000(vi) gid=1000(vi) groups=1000(vi),{many unrelated groups skipped},1057(rust),{many unrelated groups skipped}
vi$ touch myfile
vi$
Apenas o usuário "vi" tem acesso de gravação ao arquivo, apesar de g + w.
root# chown rust myfile
rust$ ls -l myfile
-rw-rw-r-- 1 rust rust 0 May 30 03:51 myfile
vi$ touch myfile
rust$ chmod g-w myfile
vi$ touch myfile
touch: cannot touch ‘myfile’: Permission denied
vi pode ou não pode gravar no arquivo rust dependendo do g + w bit, como exceção.
Por que o bit gravável em grupo funciona apenas em uma direção?
O arquivo permanece indisponível mesmo no modo a+w . O terceiro usuário pode gravar no arquivo com a+w , embora ...
getfacl myfile retorna Invalid argument .
O arquivo está em reiserfs local.
id vi e id rust correspondem a id nos respectivos grupos de usuários até a ordem de grupos não relacionados.
Mais uma experiência:
vi$ chmod a+w myfile
vi$ stat myfile
File: ‘myfile’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fb02h/64258d Inode: 12618147 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 1000/ vi) Gid: ( 1057/ rust)
Access: 2016-05-30 18:49:20.000000000 +0300
Modify: 2016-05-30 20:48:23.000000000 +0300
Change: 2016-05-30 20:48:23.000000000 +0300
Birth: -
root# dived -J -u rust -g rust -- id uid=1048(rust) gid=1057(rust) groups=1057(rust) root# dived -J -u rust -g rust -- dd of=/home/vi/home/rust/myfile dd: failed to open ‘/home/vi/home/rust/myfile’: Permission denied root# dived -J -u rust -g 99999 -- id uid=1048(rust) gid=99999 groups=99999 root# dived -J -u rust -g 99999 -- dd of=/home/vi/home/rust/myfile sfdasafd 0+1 records in 0+1 records out 9 bytes (9 B) copied, 1.14971 s, 0.0 kB/s
Um mistério. Os patches de segurança podem ser um problema?
Próxima experiência:
root# stat /home/vi/home/rust/myfile
File: ‘/home/vi/home/rust/myfile’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fb02h/64258d Inode: 13848412 Links: 1
Access: (0664/-rw-rw-r--) Uid: (99997/ UNKNOWN) Gid: (99998/ UNKNOWN)
Access: 2016-05-31 00:39:24.000000000 +0300
Modify: 2016-05-31 00:39:24.000000000 +0300
Change: 2016-05-31 00:39:24.000000000 +0300
Birth: -
root# getfacl /home/vi/home/rust/myfile
getfacl: /home/vi/home/rust/myfile: Invalid argument
root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done
0
1000
root#
root#
root# mount -o remount,noacl /home
root#
root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done | head
0
1
2
3
4
5
6
7
8
9
(and so on, basically it works)
root# mount -o remount,acl /home
root#
root# for i in {0..1099}; do if dived -J -u $i -g 99998 -- touch /home/vi/home/rust/myfile 2> /dev/null; then echo $i; fi; done | head
0
1000
root#
Parece que getfacl (ou parte do kernel) é um problema. As ACLs estão em vigor, mas não são gerenciáveis.
O problema é que o ReiserFS é negligenciado no Linux: link
ACL is broken in reiserfs from Kernel 4.4.x (Invalid argument error) 4.3.x worked fine for me...
Ainda não verifiquei como entrar nos kernels após o 4.4.
É necessário reinicializar um kernel < 4.4 para poder remover ACLs quebradas do sistema de arquivos.
Tags permissions files acl linux reiserfs