Bug 1276348 - nfs-ganesha: ACL issue after adding an ace for a user the file permissions gets modified
nfs-ganesha: ACL issue after adding an ace for a user the file permissions ge...
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: nfs-ganesha (Show other bugs)
3.1
x86_64 Linux
unspecified Severity urgent
: ---
: RHGS 3.1.2
Assigned To: Jiffin
Matt Zywusko
: ZStream
Depends On:
Blocks: 1260783
  Show dependency treegraph
 
Reported: 2015-10-29 10:06 EDT by Saurabh
Modified: 2016-03-01 00:49 EST (History)
9 users (show)

See Also:
Fixed In Version: nfs-ganesha-2.2.0-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-01 00:49:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saurabh 2015-10-29 10:06:22 EDT
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@lab.eng.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:
Comment 2 Jiffin 2015-10-30 05:41:12 EDT
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
Comment 3 Saurabh 2015-11-02 01:34:28 EST
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@lab.eng.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
Comment 4 Jiffin 2015-11-02 01:41:15 EST
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.
Comment 5 Saurabh 2015-11-03 02:24:08 EST
(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
Comment 6 Saurabh 2015-11-04 03:19:46 EST
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@lab.eng.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@lab.eng.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
Comment 7 Jiffin 2015-11-04 03:23:43 EST
K saurabh u r right , i can reproduce the issue on nfs-ganesha-2.2.0-10.el7
Comment 8 Jiffin 2015-11-04 05:23:27 EST
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.
Comment 10 Saurabh 2015-11-23 05:14:39 EST
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@lab.eng.blr.redhat.com:rtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
Comment 14 errata-xmlrpc 2016-03-01 00:49:03 EST
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

Note You need to log in before you can comment on or make changes to this bug.