Description of problem: NFS Sub directory is getting mounted on solaris 10 even when the permission is restricted to some clients only in nfs.export-dir volume option Version-Release number of selected component (if applicable): glusterfs-3.8.4-18.1.el7rhgs.x86_64 How reproducible: Consistently Steps to Reproduce: 1.Create a 6*2 Distributed-Replicate volume.Enable GNFS on it. 2.Mount the volume to solaris client via v3 and create a directory inside the mount. #mount -o proto=tcp,vers=3 nfs://10.70.42.1:/GNFSVolume/ /mnt/solmount #mkdir mani 3.Unmount the volume. 4.Provide permission to export subdirectory mani to client 10.70.37.142 only (which is other client,not solaris client) #gluster v set GNFSVolume nfs.export-dir "/mani(10.70.37.142)" volume set: success # gluster v get GNFSVolume all | grep export nfs.export-dirs on nfs.export-volumes on nfs.export-dir /mani(10.70.37.142) nfs.exports-auth-enable (null) 5.Mount the subdirectory mani to solaris client. Actual results: Mount was successful even when the client does not have that subdirectory mount permission. # mount -o proto=tcp,vers=3 nfs://10.70.42.1:/GNFSVolume/mani /mnt/solmount # cd /mnt/solmount # ls ms solarish.sh # mkdir dir1 # ls dir1 ms solarish.sh Expected results: subdirectory Mount should fail on solaris client when it doesnot have permission to mount for that client. Additional info:
This is expected behaviour. Only the MOUNT side-protocol enforces permissions when the more advanced 'exports/netgroups' feature is not used. Any NFS-client that knows a valid filehandle, can talk directly to Gluster/NFS (without the MOUNT side-protocol) to access the directory structure and files therein. With Solaris 10 clients (which use WebNFS instead of the MOUNT side-protocol) the access restructions are not enforced because the access is just like plain NFSv3. We could probably add more security checks in the WebNFS case, similar to the MOUNT protocol. I'll see what can be done there.
Hey bipin, I am able to mount the sub dir on solaris client even after restricting the IP in nfs.rpc-auth-allow Steps: 1.Create a dist-replicate volume and enable GNFS on the volume 2.Mount the vlume to solaris client and create a directory inside the volume On solaris client # mount -o proto=tcp,vers=3 nfs://10.70.42.1:/GNFSVol /mnt/mani_Solaris # cd /mnt/mani_Solaris # ls 1G 512b # mkdir mani # showmount -e 10.70.42.1 export list for 10.70.42.1: /GNFSVol * 3.Unmount the volume from solaris client # umount /mnt/mani_Solaris # /usr/sbin/ifconfig -a lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 rtls0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2 inet 10.10.188.199 netmask fffffe00 broadcast 10.10.189.255 ether 52:54:0:1a:a3:f6 4.Set the nfs.rpc-auth-allow option restricting the IP to some other range [root@dhcp42-1 /]# gluster volume set GNFSVol nfs.rpc-auth-allow 10.70.*.* volume set: success 5.On solaris client try to mount the subdir # showmount -e 10.70.42.1 export list for 10.70.42.1: /GNFSVol 10.70.*.* # mount -o proto=tcp,vers=3 nfs://10.70.42.1:/GNFSVol/mani /mnt/mani_Solaris # ls # touch f1 # ls f1 Volume Name: GNFSVol Type: Distributed-Replicate Volume ID: 6e809852-79b2-4348-b051-df4d837ab585 Status: Started Snapshot Count: 0 Number of Bricks: 6 x 2 = 12 Transport-type: tcp Bricks: Brick1: dhcp42-1.lab.eng.blr.redhat.com:/gluster/brick1/1 Brick2: dhcp41-251.lab.eng.blr.redhat.com:/gluster/brick1/1 Brick3: dhcp41-248.lab.eng.blr.redhat.com:/gluster/brick1/1 Brick4: dhcp41-245.lab.eng.blr.redhat.com:/gluster/brick1/1 Brick5: dhcp42-1.lab.eng.blr.redhat.com:/gluster/brick2/1 Brick6: dhcp41-251.lab.eng.blr.redhat.com:/gluster/brick2/1 Brick7: dhcp41-248.lab.eng.blr.redhat.com:/gluster/brick2/1 Brick8: dhcp41-245.lab.eng.blr.redhat.com:/gluster/brick2/1 Brick9: dhcp42-1.lab.eng.blr.redhat.com:/gluster/brick3/1 Brick10: dhcp41-251.lab.eng.blr.redhat.com:/gluster/brick3/1 Brick11: dhcp41-248.lab.eng.blr.redhat.com:/gluster/brick3/1 Brick12: dhcp41-245.lab.eng.blr.redhat.com:/gluster/brick3/1 Options Reconfigured: nfs.rpc-auth-allow: 10.70.*.* nfs.disable: off transport.address-family: inet ========================== Though it works correctly for fuse client On server- [root@dhcp42-1 /]# gluster volume set GNFSVol nfs.rpc-auth-allow 10.10.*.* volume set: success On client- [root@dhcp37-192 mnt]# mount -t nfs -o vers=3 10.70.42.1:/GNFSVol/mani /mnt/gnfs/ mount.nfs: access denied by server while mounting 10.70.42.1:/GNFSVol/mani ========================= @Bipin..Let me know if I am testing it correctly with the steps you provided ? Or i missed something?
Hi Bipin, nfs.rpc-auth-allow is for the whole NFS-server and is handled at the RPC layer. This option prevents any protocol provided by the NFS-server to be restricted by IP/range. This option is expected to just work for WebNFS from Solaris 10 too. Existing connections will continue to be functional, until they need a re-connect. nfs.rpc-auth-allow option is the bigger hammer, it can not make a distinction between different exports (volume or subdir). This option can be used to prevent access to the whole NFS-server. This bug has been filed for the missing support of restricting WebNFS clients with "nfs.export-dir=<subdir>(<allow-deby-acl>)" option. That is something that has not been implemented for WebNFS. Does that help? Niels
Niels, As discussed over IRC, We see some issue while using FQDN/hostname for nfs.rpc-auth-allow . Behavior is not as expected. Although using ip behaves well. I will open separate bug for it. -Regrads, Bipin
The problem is reproducible. Even with the (now corrected) patch from comment #4, the Solaris client is able to mount a subdir over WebNFS that should be denied. More debugging is needed to verify what functions incorrectly (?) parse the (missing?) client auth.
Upstream patch: https://review.gluster.org/17718
A fixup for this feature has been posted at https://review.gluster.org/17822 This should prevent the segfault that Manisha reported over IRC.
Verified this bug on glusterfs-3.8.4-38.el7rhgs.x86_64 Steps: 1.Create a 2 x (4 + 2) Distributed-Disperse Volume 2.Export the volume via GNFS 3.Mount the volume to solaris client.Create a sub dir inside the mount mount -bash-3.00# mount -o proto=tcp,vers=3 nfs://10.70.42.1:/disperseVol /mnt/GNFSMOunt/ -bash-3.00# cd /mnt/GNFSMOunt/ l-bash-3.00# ls msaini 4.Unmount the volume 5.Mount the subdir on solaris client created at step 3 -bash-3.00# mount -o proto=tcp,vers=3 nfs://10.70.42.1:/disperseVol/mani /mnt/GNFSMOunt/ 6.Unmount the subdir -bash-3.00# umount /mnt/GNFSMOunt/ 7.Restrict the volume to some IP other then solaris client IP # gluster v set disperseVol nfs.export-dir "/mani(10.70.37.142)" volume set: success 8.Now again try mounting the same subdir "mani" on solaris client.Mount fails as the solaris client doesnot have permission to mount. -bash-3.00# mount -o proto=tcp,vers=3 nfs://10.70.42.1:/disperseVol/mani /mnt/GNFSMOunt/ nfs mount: 10.70.42.1: : RPC: Program not registered nfs mount: retrying: /mnt/GNFSMOunt While verifying this bug at some step,hit crash (once) reported in BZ -https://bugzilla.redhat.com/show_bug.cgi?id=1476871. Will try to narrow down the exact steps for the BZ-1476871 and will update the bug. As the issue reported in this bug is resolved,moving this bug to verified state
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://access.redhat.com/errata/RHBA-2017:2774