Users vi and rust share group rust and want to use some file in shared manner.
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$
Only "vi" user has write access to the file despite of 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 can or can't write to rust's file depending on g+w bit, as excepted.
Why group-writable bit works only in one direction?
The file remains unavailable even in a+w mode. Third user can write to the file with a+w although...
getfacl myfile returns Invalid argument.
The file is on local reiserfs.
id vi and id rust matches id in respective users' shells up to order of unrelated groups.
One more experiment:
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
A mystery. Can grsecurity patches be a problem?
Next experiment:
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#
Looks like getfacl (or it's kernel part) is a problem. ACLs are in effect, but are not manageable.
