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.

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.

Created attachment 425597 [details]
patch -- split vs_hidden into UDP and TCP specific flags

Proposed patch. Compile tested but needs testing for functionality.

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.

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...

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.

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.

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.

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...

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.

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.

Lets move this to RHEL7... Unfortunately I do not see an easy way to do that..

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.