group member unable to write to a group-writable file with reiserfs and extended ACLs

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.