7

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.

9
  • See unix.stackexchange.com/a/15042/117549
    – Jeff Schaller
    May 30, 2016 at 1:46
  • @JeffSchaller, It is not specific to touch. With printf '' >> myfile it is the same. I see open("myfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) in strace.
    – Vi.
    May 30, 2016 at 10:00
  • If vi can't write to a rw-rw-rw- file (no ACL) and a user who isn't either vi 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? May 30, 2016 at 20:51
  • No relevant logs (in grsecurity case it is dmesg). 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).
    – Vi.
    May 30, 2016 at 21:30
  • 1
    mount -o remount,noacl /home turns off the mystery. mount -o remount,acl /home turns it on again. getfacl fails in both cases.
    – Vi.
    May 30, 2016 at 21:40

1 Answer 1

0

The problem is ReiserFS being neglected in Linux: https://bbs.archlinux.org/viewtopic.php?id=197628

ACL is broken in reiserfs from Kernel 4.4.x (Invalid argument error) 4.3.x worked fine for me...

I haven't checked yet how to goes in kernels after 4.4.

One need to reboot to a kernel <4.4 to be able to remove broken ACLs from the filesystem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .