Description of problem: ====================== From NFS mount, non-root user who has no access to a directory, is able to access the snaps and files under .snaps under that directory Version-Release number of selected component (if applicable): ============================================================ glusterfs 3.6.0.32 How reproducible: ================= 2/2 Steps to Reproduce: ================== 1.Create a 2x2 dist-rep volume and start it 2.Fuse and NFS mount the volume Create 2 users (user1, user2) 3.Enable USS on the volume 4.From fuse mount, create dir1_fuse Give permissions to dir1_fuse as chmod 700 user1 Create files a{1..10} under dir1_fuse 5.From nfs mount, create dir1_nfs Give permissions to dir1_nfs as chmod 700 user1 Create files b{1..10} under dir1_nfs 6.Create snapshot Snap1 7.Login as user1 : =============== From fuse mount, cd to .snaps and list the snapshots access the files under them. From nfs mount, cd to .snaps and list the snapshots access the files under them 8.Login as user2 : =============== From fuse mount, cd to .snaps and list the snapshots access the files under them -> it fails with 'Permission denied' error which is as expected [user2@dhcp-0-97 Snap1]$ ll total 0 drwx------. 2 user1 root 61 Nov 17 19:21 dir1_fuse drwx------. 2 user1 root 52 Nov 17 19:22 dir1_nfs [user2@dhcp-0-97 Snap1]$ cd dir1_fuse/ bash: cd: dir1_fuse/: Permission denied From nfs mount, cd to .snaps and list the snapshots access the files under them - it is successful. user2 is able to list the snapshots and access the files under .snaps of dir1_nfs for which he has no access. Instead user2 should get 'Permission denied' error [user2@dhcp-0-97 Snap1]$ cd dir1_nfs/ [user2@dhcp-0-97 dir1_nfs]$ ll total 0 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b1 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b10 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b2 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b3 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b4 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b5 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b6 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b7 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b8 -rw-rw-r--. 1 user1 user1 0 Nov 17 19:22 b9 Actual results: =============== From NFS mount, non-root user who has no access to a directory, is able to access the snaps and files under .snaps under that directory Expected results: ================ non root user who has no access to any directory should not be able to access .snaps and access the files under the snapshots listed under that directory. Additional info:
Did a initial RCA on this. The problem is not in snapd, but it is in the way we handle access call using glfs api. Whenever a access call from glfs is issued a new frame is create in which uid and gid is set to root instead of the user's uid and gid.
https://code.engineering.redhat.com/gerrit/#/c/37603/ Fixes the issue.
Version : glusterfs 3.6.0.38 ======== Non root user who has no access to a directory gets "Permission denied" error as expected when he tried to access the files under .snaps under that directory. Behavior is the same from fuse and nfs mount Non root user (S2) has no access to a1_fuse and a1_nfs. Fuse mount : =========== [S2@dhcp-0-97 vol_f]$ cd a1_fuse/ bash: cd: a1_fuse/: Permission denied [S2@dhcp-0-97 vol_f]$ cd .snaps [S2@dhcp-0-97 .snaps]$ ll total 0 drwxr-xr-x. 5 S1 root 300 Dec 12 15:16 SN1 [S2@dhcp-0-97 .snaps]$ cd SN1/ [S2@dhcp-0-97 SN1]$ ll total 0 drwx------. 2 S1 root 24 Dec 12 15:19 a1_fuse drwx------. 2 S1 root 6 Dec 12 15:18 a1_nfs [S2@dhcp-0-97 SN1]$ cd a1_fuse/ bash: cd: a1_fuse/: Permission denied NFS mount : ========== [S2@dhcp-0-97 .snaps]$ cd SN1/ [S2@dhcp-0-97 SN1]$ ll total 0 drwx------. 2 S1 root 127 Dec 12 15:19 a1_fuse drwx------. 2 S1 root 127 Dec 12 15:18 a1_nfs [S2@dhcp-0-97 SN1]$ cd a1_nfs/ bash: cd: a1_nfs/: Permission denied Marking the bug as 'Verified'
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-2015-0038.html