Description of problem: for nfs-ganesha nfs4 acls I see a strange behaviour about the change in file permissions. Several users are created say(user_a, user_b) both belonging to same group. A file created with user_a credentials. The file permissions are modified as read-write only for user_a. Now, user_b related ace is added, nfs4_setfacl -a A::user_b@${DOMAIN}:R file and then I see that the file change to "0666" Version-Release number of selected component (if applicable): glusterfs-3.7.5-0.3.el7rhgs.x86_64 nfs-ganesha-2.2.0-10.el7rhgs.x86_64 How reproducible: always Steps to Reproduce: 1. do the setup related to nfs-ganesha 2. enable acls 3. mount the volume with vers=4 4. create a dir and create a file called as "file" inside the directory 5. create users on server as well as on client with specific ids using commands, useradd -u 1501 user_a useradd -u 1502 user_b groupadd -g 2001 group1 usermod -a -G group1 user_a usermod -a -G group1 user_b 6. chown 0600 file 6.1 ls -l file 7. nfs4_setfacl -a A::user_b@${DOMAIN}:R file 8. ls -l file Actual results: step 6, # ll /mnt/acl-test/NOTES.jiffin -rw-------. 1 user_a user_a 29 Oct 30 2015 /mnt/acl-test/file step 7, # nfs4_getfacl /mnt/acl-test/file A::OWNER@:rwatTcCy A::user_b.blr.redhat.com:rwatcy A::GROUP@:rwatcy A::EVERYONE@:rwatcy step8, # ls -l /mnt/acl-test/file -rw-rw-rw-. 1 user_a user_a 29 Oct 30 2015 /mnt/acl-test/file Expected results: file permissions should not change for Others and group just by adding a ace for particular user Additional info:
For me a similar behavior occurred in my setup too. Only second field got filled with permission of second user This is due to the mask entry(umask) in posix acl. When there is a named user or group entry mask entry will be populated and due to that ls -ltr throws permission due to this. But even though this permission is showed, only second can read the file . The same behavior is noted in kernel NFS too Steps I followed is mentioned below On the client ---------------- #touch file # chown user_a@${DOMAIN} file # chmod 600 file # nfs4_getfacl file A::OWNER@:rwatTcCy A::GROUP@:tcy A::EVERYONE@:tcy On server side --------------- # getfacl file # file: file # owner: user_a # group: root user::rw- group::--- other::--- # ls -ltr file -rw------- 2 user_a root 0 Oct 30 14:36 file On the client --------------- # nfs4_setfacl -a A::user_b@${DOMAIN}:R file # nfs4_getfacl file A::OWNER@:rwatTcCy A::user_b@${DOMAIN}:rtcy A::GROUP@:tcy A::EVERYONE@:tcy [root@fedora20 0]# ls -ltr file -rw-r-----. 1 user_a root 0 Oct 30 14:36 file On server the side ------------------- # getfacl file # file: file # owner: user_a # group: root user::rw- user:user_b:r-- group::--- mask::r-- other::--- # ls -ltr file -rw-r-----+ 2 user_a root 0 Oct 30 14:36 file
I did as per mentioned in comment #2 of this bz. Getting the similar results, still the other user i.e. "user_b" is not able to read the file, # nfs4_getfacl /mnt/acl_test/file A::OWNER@:rwatTcCy A::user_b.blr.redhat.com:rtcy A::GROUP@:tcy A::EVERYONE@:tcy # su user_b [user_b@]$ cat /mnt/acl_test/file cat: /mnt/acl_test/file: Permission denied from server side, # getfacl /rhs/brick1/d1r1/acl_test/file getfacl: Removing leading '/' from absolute path names # file: rhs/brick1/d1r1/acl_test/file # owner: user_a # group: user_a user::rw- user:4294967294:r-- group::--- mask::r-- other::--- [root@]# ls -l /rhs/brick1/d1r1/acl_test/file -rw-r-----+ 2 user_a user_a 6 Nov 2 19:47 /rhs/brick1/d1r1/acl_test/file
This is a idmapping issue , u can see user_b is mapped to anonymous id (4294967294) at the server side , so that it will get a permission denied error.
(In reply to Jiffin from comment #4) > This is a idmapping issue , u can see user_b is mapped to anonymous id > (4294967294) at the server side , so that it will get a permission denied > error. Oh yes, I missed to check the id was wrong on the server and after making the change I see that the file is readable by the user user_b # su user_b sh -c "cat /mnt/acl_test/file" # echo $? 0
As mentioned in the description, I was able to reproduce the issue, as can be seen that file "file1" is having 0600 permissions # ls -l file1 -rw-------. 1 user_a user_a 0 Nov 4 2015 file1 # nfs4_getfacl file1 A::OWNER@:rwatTcCy A::GROUP@:tcy A::EVERYONE@:tcy but after, setting the acl for a user "user_b" of same group # nfs4_setfacl -a A::user_b.blr.redhat.com:R file1 the file permissions will change, # ls -l file1 -rw-rw-rw-. 1 user_a user_a 0 Nov 4 2015 file1 # nfs4_getfacl file1 A::OWNER@:rwatTcCy A::user_b.blr.redhat.com:rwatcy A::GROUP@:rwatcy A::EVERYONE@:rwatcy on server side , the getfacl is as mentioned, # getfacl /rhs/brick1/d[2-6]r1/acl_test/file1 getfacl: Removing leading '/' from absolute path names # file: rhs/brick1/d6r1/acl_test/file1 # owner: user_a # group: user_a user::rw- user:user_b:rw- group::rw- mask::rw- other::rw- the rpms of the glusterfs and nfs-ganesha are, glusterfs-3.7.5-5.el7rhgs.x86_64 nfs-ganesha-2.2.0-10.el7rhgs.x86_64
K saurabh u r right , i can reproduce the issue on nfs-ganesha-2.2.0-10.el7
The one of the check in upstream patch is missed out while backporting. Sorry for the mistake. I created a downstream patch to fix the issue.
checked the permissions on the latest build, nfs-ganesha-2.2.0-11.el7rhgs.x86_64 # nfs4_getfacl /mnt/acl-test/NOTES.jiffin A::OWNER@:rwatTcCy A::niels.blr.redhat.com:rtcy A::GROUP@:tcy A::EVERYONE@:tcy
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0193.html