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.
touch
. Withprintf '' >> myfile
it is the same. I seeopen("myfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)
in strace.vi
can't write to arw-rw-rw-
file (no ACL) and a user who isn't eithervi
or the owner can write to the file, this can't be explained by usual Unix permissions. So yes, I'd lean towards some configuration of a security module. Have you checked logs?vi
, as owner, can write to the file. The access disappears when group 1057 gets added to the process's group list. I've set file's ower to 99998 and tried looping over uids; it works in this mode only from uid=1000 and uid=0 (although I don't see 1000 in file's stat).mount -o remount,noacl /home
turns off the mystery.mount -o remount,acl /home
turns it on again.getfacl
fails in both cases.