Hide Forgot
Description of problem: 1. Proposed title of this feature request SECINFO support in the NFS v4 client in RHEL 6 2. Who is the customer behind the request? Account name:UBS AG Customer segment:Nil TAM/SRM customer: no/yes, SRM customer Strategic Customer yes/no:Yes 3. What is the nature and description of the request? We would like to have SECINFO support in the NFS v4 client in RHEL 6. It is currently supported server side, we require it on the NFS v4 client side as well. 4. Why does the customer need this? (List the business requirements here) This is the business requirement customer provided: "Computers are much better at getting things right automatically then humans are at making sure that two sides are configured correctly. Think of network port autonegotiation, ever since we leave the ports to figure out what to configure, things work a lot more reliably. Back when a network and an OS support person had to agree on the settings, thing ended up wrong in a lot of cases. The same can be transfered over to the export/mount options to use and the storage and OS support person having to agree on the right setting. It's a lot more reliable if just one side is maintained (the export) and the other side does the right thing automatically. And then think of the automounter, if you want to introduce strong authentication for home directories, you need to start injecting the options into the automounter map, but only on the home directories which have already been migrated to use secure NFS. A nightmare maintaining that map! Things will work so much more reliably if the OS does the right thing and the security is controlled from the export on the storage device only. Ease of use means less administrative overhead which in turn means lower support cost. Negotiation means eliminating human error, means less outages, means more stable environment. Lower cost and a stable environment is what we want". 5. How would the customer like to achieve this? (List the functional requirements here) When the customer did the following: [root@xldn6100nap tmp]# mount sldn6016nap:/export/krb5 /mnt/mo mount.nfs: access denied by server while mounting sldn6016nap:/export/krb5 [root@xldn6100nap tmp]# mount -o sec=krb5 sldn6016nap:/export/krb5 /mnt/mo [root@xldn6100nap tmp]# umount /mnt/mo The first command does not specify the security mode, it is here where the client should use SECINFO to learn the security mode to use. But it doesn't, the mount fails. In the second invocation, he specified the security mode as option (-o sec=krb5) and the mount is successful. He says, if he executes the first command from a Solaris host as NFS client to the Linux NFS server, the command succeeds. Solaris correctly implements the Security Negotiation on the NFS client. Linux doesn't. 6. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. See above 7. Is there already an existing RFE upstream or in Red Hat bugzilla? No 8. Does the customer have any specific timeline dependencies? No 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages: kernel-2.6.32-131.17.1.el6.x86_64 11. Would the customer be able to assist in testing this functionality if implemented? Yes
commit 8f70e95f9f4159184f557a1db60c909d7c1bd2e3 Author: Bryan Schumaker <bjschuma> Date: Thu Mar 24 17:12:31 2011 +0000 NFS: Determine initial mount security Here are the initial patches: commit 7ebb931598cd95cccea10d4bc4c0123a464ea565 Author: Bryan Schumaker <bjschuma> Date: Thu Mar 24 17:12:30 2011 +0000 NFS: use secinfo when crossing mountpoints commit 5a5ea0d485c9715c86bf858bbdc5f6d373b3db88 Author: Bryan Schumaker <bjschuma> Date: Thu Mar 24 17:12:29 2011 +0000 NFS: Add secinfo procedure commit 7c5130588d691a3b34d02312f1bd1b6d56fe0100 Author: Bryan Schumaker <bjschuma> Date: Thu Mar 24 17:12:24 2011 +0000 NFS: lookup supports alternate client commit e73b83f270828630a9ce33728f6ef61c37a82340 Author: Bryan Schumaker <bjschuma> Date: Thu Mar 24 17:12:23 2011 +0000 NFS: convert call_sync() to a function And these seem to be the supplement ones: commit 05e9cfb408b24debb3a85fd98edbfd09dd148881 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Mar 27 18:13:02 2012 -0400 NFSv4: Fix two infinite loops in the mount code commit 613e901e1ee0e1096663b649eee8e5d6697919f3 Author: Bryan Schumaker <bjschuma> Date: Wed Apr 27 15:28:44 2011 -0400 NFS: Return meaningful status from decode_secinfo() commit fca78d6d2c77f87d7dbee89bbe4836a44da881e2 Author: Bryan Schumaker <bjschuma> Date: Thu Jun 2 14:59:07 2011 -0400 NFS: Add SECINFO_NO_NAME procedure commit 1650add23578b5ca35c1f1e863987180a8c03779 Author: Bryan Schumaker <bjschuma> Date: Thu Jun 2 15:07:35 2011 -0400 NFS: Fix decode_secinfo_maxsz commit c6e696660213a89a5bfde8b49d539553904c808f Author: Chuck Lever <chuck.lever> Date: Tue Oct 25 12:17:53 2011 -0400 NFS: Clean up nfs4_xdr_dec_secinfo()
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Reproducer refer to comment 0, and regression test is needed
Patch(es) available on kernel-2.6.32-288.el6
Test as comment 1, secinfo work well. crossmnt also is tested, test case refer to /kernel/filesystems/nfs/mnt_secinfo Part of test output: # hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST should be access by sec=krb5,krb5i,krb5p # mount with mount -o vers=4 hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST /mnt/TEST # check from /mnt/mounts hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST /mnt/TEST nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.66.86.85,minorversion=0,local_lock=none,addr=10.66.86.85 0 0 # do some op # umount /mnt/TEST # mount with mount -o vers=4 hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5 /mnt/TEST # check from /mnt/mounts hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5 /mnt/TEST nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.66.86.85,minorversion=0,local_lock=none,addr=10.66.86.85 0 0 # do some op # mount with mount -o vers=4 hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5i /mnt/TEST # check from /mnt/mounts hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5i/ /mnt/TEST nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=10.66.86.85,minorversion=0,local_lock=none,addr=10.66.86.85 0 0 # do some op # mount with mount -o vers=4 hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5p /mnt/TEST # check from /mnt/mounts hp-xw4600-01.rhts.eng.nay.redhat.com:/tmp/TEST/krb5p/ /mnt/TEST nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5p,clientaddr=10.66.86.85,minorversion=0,local_lock=none,addr=10.66.86.85 0 0 # do some op
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. http://rhn.redhat.com/errata/RHSA-2013-0496.html
Created attachment 772932 [details] Includes sosreport and other bug and error log files This is in relation to earlier case: 00577585 [RFE] NFS v4 Security Flavor Negotiation The bug associated with the case https://bugzilla.redhat.com/show_bug.cgi?id=784174 has been implemented and shipped with RHEL 6.4: http://rhn.redhat.com/errata/RHSA-2013-0496.html Customer has been testing the implementation and unfortunately NFS v4 security negotiation is not yet working against NetApp filers as NFS server. ONTAP also had a Security Negotiation bug http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=558782 but the fix is now available. Customer has been able to verify that the fix is working with a Solaris client. (all relevant info attached)