RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 784174 - SECINFO support in the NFS v4 client in RHEL 6
Summary: SECINFO support in the NFS v4 client in RHEL 6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Jian Li
URL:
Whiteboard:
Depends On:
Blocks: 806907 846704
TreeView+ depends on / blocked
 
Reported: 2012-01-24 05:33 UTC by Remya Valappil
Modified: 2018-11-30 22:43 UTC (History)
8 users (show)

Fixed In Version: kernel-2.6.32-288.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 06:01:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0496 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 6 kernel update 2013-02-20 21:40:54 UTC

Description Remya Valappil 2012-01-24 05:33:18 UTC 
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
Comment 4 Steve Dickson 2012-04-05 13:44:34 UTC 
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()
Comment 7 RHEL Program Management 2012-06-27 13:41:55 UTC 
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.
Comment 8 Jian Li 2012-07-04 07:47:21 UTC 
Reproducer refer to comment 0, and regression test is needed
Comment 9 Jarod Wilson 2012-07-23 17:16:06 UTC 
Patch(es) available on kernel-2.6.32-288.el6
Comment 13 Jian Li 2013-01-18 06:19:21 UTC 
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
Comment 15 errata-xmlrpc 2013-02-21 06:01:48 UTC 
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
Comment 16 Tanmoy Chakraborty 2013-07-13 01:14:18 UTC 
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)
Note You need to log in before you can comment on or make changes to this bug.