Bug 606260 - (NFS server): Disable NFSv4 over UDP
Summary: (NFS server): Disable NFSv4 over UDP
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: J. Bruce Fields
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 767187 606263 609113 1431683
TreeView+ depends on / blocked
 
Reported: 2010-06-21 09:28 UTC by Sachin Prabhu
Modified: 2018-11-28 19:21 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The NFSv4 server in Red Hat Enterprise Linux 6 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. However, this configuration is not supported by Red Hat and violates the RFC 3530 standard.
Clone Of:
: 606263 609113 1431683 (view as bug list)
Environment:
Last Closed: 2012-01-06 18:35:08 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch -- split vs_hidden into UDP and TCP specific flags (4.19 KB, patch)
2010-06-21 10:47 UTC, Jeff Layton
no flags Details | Diff

Description Sachin Prabhu 2010-06-21 09:28:22 UTC
This bugzilla has been raised for the NFS Server part in the kernel.

At the moment on RHEL 6 beta, we support NFSv4 over UDP. 

RFC3530 states

   Where an NFS version 4 implementation supports operation over the IP
   network protocol, the supported transports between NFS and IP MUST be
   among the IETF-approved congestion control transport protocols, which
   include TCP and SCTP

UDP doesn't perform congestion control. This combination is thus not standards compliant.

I came across this thread upstream.
http://linux-nfs.org/pipermail/nfsv4/2006-February/003480.html

Comment 1 RHEL Product and Program Management 2010-06-21 09:43:20 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Jeff Layton 2010-06-21 10:39:06 UTC
I'll take this one since I have an initial stab at a patch for it. It'll need to go upstream though and I'd like to have Steve's feedback on it before I try to push it there.

Comment 3 Jeff Layton 2010-06-21 10:47:24 UTC
Created attachment 425597 [details]
patch -- split vs_hidden into UDP and TCP specific flags

Proposed patch. Compile tested but needs testing for functionality.

Comment 4 Jeff Layton 2010-06-21 10:48:50 UTC
And to be clear...the plan isn't to disable NFSv4 over UDP altogether. The RPC layer doesn't really have infrastructure to do that simply at this time. This patch will just stop the server from registering the NFSv4 UDP port with rpcbind.

Comment 5 Jeff Layton 2010-06-28 10:32:31 UTC
Trond shot down the patch to just disable rpcbind registration. He wants us to block access to the service via UDP too. I made a couple of passes at patches to do that last week, but they seem to be moving into the "piling hacks on hacks" category. At this point I think we need to take a hard look at fixing this in a more structural way, which is what Peter S. and Chuck L. recommended in the threads where we discussed this.

It's going to take some time to get that done. I suggest that we move this BZ out to 6.1 and plan to release-note this. I'll reset the flags to do that...

Comment 6 Jeff Layton 2010-06-28 10:32:31 UTC
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
The NFSv4 server in RHEL6.0 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. Doing so however is in violation of RFC 3530 and is not supported by Red Hat.

Comment 7 Ryan Lerch 2010-06-29 00:42:35 UTC
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-The NFSv4 server in RHEL6.0 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. Doing so however is in violation of RFC 3530 and is not supported by Red Hat.+The NFSv4 server in Red Hat Enterprise Linuz 6 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. However, this configuration is not supported by Red Hat and violates the RFC 3530 standard.

Comment 8 Ryan Lerch 2010-06-29 00:43:01 UTC
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-The NFSv4 server in Red Hat Enterprise Linuz 6 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. However, this configuration is not supported by Red Hat and violates the RFC 3530 standard.+The NFSv4 server in Red Hat Enterprise Linux 6 currently allows clients to mount using UDP and advertises the NFSv4 over UDP with rpcbind. However, this configuration is not supported by Red Hat and violates the RFC 3530 standard.

Comment 9 Jeff Layton 2010-07-19 10:42:13 UTC
Reassigning this to Bruce. Here is my (handwavy) thinking on how to fix this...you can look over the upstream discussion from a few weeks ago.

I did some hacks to try and fix just this problem but then noticed a related bug:

$ rpcinfo -n 2049 -u server 100003 1
rpcinfo: RPC: Program/version mismatch; low version = 2, high version = 4
program 100003 version 1 is not available

...the low and high versions returned in this case are not governed by the /proc/fs/nfsd/versions interface. I think that should also be fixed while we're in here.

I think the right way to fix this is probably to alter the RPC layer such that the svc_version is a per-xprt thing. That'll take a bit of reorganization though. The hierarchy is currently:

svc_serv->svc_program->svc_version
    |
    +---->svc_xprt

So we may need to move the sv_permsocks and sv_tempsocks lists to hang off of the svc_program instead. There may be a simpler way to do this that I'm not seeing though...

Comment 11 RHEL Product and Program Management 2011-01-07 03:58:03 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 12 J. Bruce Fields 2012-01-06 16:56:42 UTC
OK, I agree with Comment 9: in the specific case of v4 making the returned version range per-transport may not matter as a client should know not to attempt v4/udp--but more generally if we allow supported versions to vary by transport, then making that range per-transport would be the most helpful for an rpc client negotiating a program version over some given transport.

Though in practice probably clients don't depend on the returned range enough for this to be very important.

Comment 13 Steve Dickson 2012-01-06 18:28:50 UTC
Lets move this to RHEL7... Unfortunately I do not see an easy way to do that..

Comment 14 RHEL Product and Program Management 2012-01-06 18:35:08 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


Note You need to log in before you can comment on or make changes to this bug.