REVIEW: http://review.gluster.org/9340 (USS : fill proper uid and gid during a access call from nfs) posted (#1) for review on release-3.6 by Sachin Pandit (spandit)
REVIEW: http://review.gluster.org/9340 (USS : fill proper uid and gid during a access call from nfs.) posted (#2) for review on release-3.6 by Sachin Pandit (spandit)
COMMIT: http://review.gluster.org/9340 committed in release-3.6 by Raghavendra Bhat (raghavendra) ------ commit f19d5d1a704fda90743f8ff161ca7174cae2f48f Author: Sachin Pandit <spandit> Date: Tue Nov 25 07:20:38 2014 +0530 USS : fill proper uid and gid during a access call from nfs. Problem : when an user tries to access a file/folder for which he does not have a proper permission required then fuse gives out a proper error "Permission denied", but nfs does not give out that error, rather he can access the file/folder. The reason being uid and gid of call frame stack takes a default value of uid and gid which point to root permission. Solution : Set a proper uid and gid during a access call from nfs Change-Id: Ib060706fde66ec7e60f242fab1f3e59122ed2245 BUG: 1175739 Signed-off-by: Sachin Pandit <spandit> Reviewed-on: http://review.gluster.org/9194 Reviewed-by: Vijaikumar Mallikarjuna <vmallika> Reviewed-by: Rajesh Joseph <rjoseph> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Vijay Bellur <vbellur> Signed-off-by: Sachin Pandit <spandit> Reviewed-on: http://review.gluster.org/9340 Reviewed-by: Raghavendra Bhat <raghavendra>
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.
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.6.2, please reopen this bug report. glusterfs-3.6.2 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should already be or become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. The fix for this bug likely to be included in all future GlusterFS releases i.e. release > 3.6.2. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/5978 [2] http://news.gmane.org/gmane.comp.file-systems.gluster.user [3] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137