[Bugs] [Bug 1177899] New: nfs: ls shows "Permission denied" with root-squash

Wed Dec 31 07:35:13 UTC 2014

https://bugzilla.redhat.com/show_bug.cgi?id=1177899

            Bug ID: 1177899
           Summary: nfs: ls shows "Permission denied" with root-squash
           Product: GlusterFS
           Version: 3.6.1
         Component: nfs
          Severity: medium
          Priority: medium
          Assignee: bugs at gluster.org
          Reporter: vbellur at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com,
                    mmadhusu at redhat.com, ndevos at redhat.com,
                    saujain at redhat.com, vagarwal at redhat.com
        Depends On: 1161092

+++ This bug was initially created as a clone of Bug #1161092 +++

Description of problem:
the problem is seen till now only in one scenario, where root-squash is enabled
on volume, after a umount and a subsequent mount of the same volume throws ls
only for a single file, not for others.

workaround, follow this sequence 
1. umount the volume
2. disable root-squash on the volume
3. mount the volume
4. enable the root-squash on the same volume, 

the ls does not throw any error.

How reproducible:
always

Steps to Reproduce:
1. create a volume of 6x2 type
2. mount the volume over nfs
3. create directory say "dir3"
4. create a file say "3" and chmod 770 <mount-point>/dir3/3
5. enable root-squash
6. umount <mount-point>
7. mount <mount-point>
8. ls -lR <mount-point>

Actual results:
[root at rhsauto054 ~]# ls -lR /mnt/nfs-test/
/mnt/nfs-test/:
total 0
drwxrwxrwx. 2 root root 76 May 27 12:05 dir1
drwxr-xr-x. 2 root root 44 May 27 11:48 dir2
drwxr-xr-x. 2 root root 44 May 27 11:48 dir3
drwxr-xr-x. 2 root root 36 May 27 11:48 dir4

/mnt/nfs-test/dir1:
total 1
-rwxrwxrwx. 1 root      root       6 May 27 11:49 1
-rw-r--r--. 1 root      root       0 May 27 01:17 newfile
-rw-r--r--. 1 nfsnobody nfsnobody 17 May 27 01:27 nobody-file

/mnt/nfs-test/dir2:
total 1
-rwxrwxrwx. 1 root root 6 May 27 11:49 2

/mnt/nfs-test/dir3:
ls: /mnt/nfs-test/dir3/3: Permission denied
total 0
-rwxrwx---. 1 root root 0 May 27 01:06 3

/mnt/nfs-test/dir4:
total 0

check the permission denied error for dir3/3

nfs.log glimpse,
[2014-05-26 20:59:03.738805] W [client-rpc-fops.c:1088:client3_3_getxattr_cbk]
0-dist-rep-client-4: remote operation failed: Permission denied. Path:
<gfid:c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd>
(c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd). Key: (null)
[2014-05-26 20:59:03.739852] W [client-rpc-fops.c:1088:client3_3_getxattr_cbk]
0-dist-rep-client-5: remote operation failed: Permission denied. Path:
<gfid:c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd>
(c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd). Key: (null)
[2014-05-26 20:59:08.975778] W [client-rpc-fops.c:1088:client3_3_getxattr_cbk]
0-dist-rep-client-4: remote operation failed: Permission denied. Path:
<gfid:c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd>
(c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd). Key: (null)
[2014-05-26 20:59:08.976858] W [client-rpc-fops.c:1088:client3_3_getxattr_cbk]
0-dist-rep-client-5: remote operation failed: Permission denied. Path:
<gfid:c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd>
(c3a3e8c5-0654-4de9-acdf-1a3562d4e1fd). Key: (null)

Expected results:
no permission denied expected

Additional info:

--- Additional comment from Meghana on 2014-11-04 07:15:47 EST ---

The behaviour is seen on all the files that are created following the steps
that are listed in the "Steps to reproduce" section. Packet trace shows
expected ACCESS reply, allowing read and lookup permissions for the file. There
are errors seen in server_getxattr_cbk.Yet to root cause the issue.

--- Additional comment from Niels de Vos on 2014-11-05 10:34:00 EST ---

Capturing what we discussed earlier today. Permission denied comes from
xlators/system/posix-acl/src/posix-acl.c:acl_permits():

 ...
 212         for (i = 0; i < acl->count; i++) {
 213                 switch (ace->tag) {
 ...
 245                 case POSIX_ACL_OTHER:
 246                         perm = (ctx->perm & S_IRWXO);
 247                         if (!found)
 248                                 goto perm_check;
 ...
 269 perm_check:
 270         if ((perm & want) == want) {
 271                 goto green;
 272         } else {
 273                 goto red;
 274         }
 ...

acl_permits() lands in the switch statement at POSIX_ACL_OTHER. 'found' is
false, so it goes to 'perm_check', where the if-statement results in the 'else'
branch.

I do not remember what the 'want' was though... Please attach a tcpdump and
output from rpcdebug captured on the NFS-client so that I can review it.

Thanks!

--- Additional comment from Meghana on 2014-11-05 12:25:33 EST ---

The value of want was 4 in this case.

--- Additional comment from Meghana on 2014-11-05 12:54:55 EST ---

--- Additional comment from Meghana on 2014-11-06 03:38:17 EST ---

Attaching rpcdebug output on the NFS client.

--- Additional comment from Anand Avati on 2014-11-06 12:32:31 EST ---

REVIEW: http://review.gluster.org/9064 (When OTHERS are not given any
permissions, ACLs are not displayed. Even when there are no permissions to any
of the users/groups/others, ACLs and attrs have to be disaplyed. Fixed this by
removing unnecessary checks. Signed-off-by: Meghana Madhusudhan
<mmadhusu at redhat.com>) posted (#1) for review on master by Meghana M
(mmadhusu at redhat.com)

--- Additional comment from Anand Avati on 2014-11-10 05:17:52 EST ---

REVIEW: http://review.gluster.org/9085 (When root-squash is enabled or when no
permissions are given to a file, NFS threw permission errors. According to the
kernel-nfs behaviour, no permissions were required to read ACLs and other
extended attributes.) posted (#1) for review on master by Meghana M
(mmadhusu at redhat.com)

--- Additional comment from Meghana on 2014-11-10 05:19:31 EST ---

I have attached kernel-nfs logs here. I performed numerous tests on kernel-nfs
and observed a few things.
1. It doesn't require read permissions  for getfacl, ls -l and getfattr
commands.
2. Using getfattr commands on an NFS mount, we can only see the nfs_acl attrs.
3. I set extended attributes on the file on a fuse mount. On an NFS mount it is
not visible.
4. Extended attrs could not be set on the file on an NFS mount. setfattr
commands
are not supported on NFS.
5. nfs4_acl xattrs were visible to the client, without any permissions.

Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1161092
[Bug 1161092] nfs: ls shows "Permission denied" with root-squash
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.