Eric Kustarz's Weblog

e-street

All | FileBench | NFS | SETUP | ZFS

« NFSv4 Client's Recov... | Main | nasconf 2005 »
20050815 Monday August 15, 2005

 Default Use of Privileged Ports Changed

Default Use of Privileged Ports Changed

Noel recently changed (putback in snv_22) the Solaris NFS client's default behavior for port selection. Previously, the client would default to using privileged ports via the variables 'clnt_cots_do_bindresvport' for TCP and 'clnt_clts_do_bindresvport' for UDP.

Why did we set the default set for privileged ports in the first place way back when? It served its purpose in the older days of insecure NFS, where servers would automatically deny client requests using a non-reserved port. Now with RPCSEC_GSS, we can move forward.

Another piece to this puzzle, is nfs_portmon. It has this comment in the code: 

/*
 * If nfs_portmon is set, then clients are required to use privileged
 * ports (ports < IPPORT_RESERVED) in order to get NFS services.
 *
 * N.B.: this attempt to carry forward the already ill-conceived notion
 * of privileged ports for TCP/UDP is really quite ineffectual.  Not only
 * is it transport-dependent, it's laughably easy to spoof.  If you're
 * really interested in security, you must start with secure RPC instead.
 */
static int nfs_portmon = 0;

And can be found in nfsd(1M). Turning it on forces the server to only accept privileged ports. Since i dislike nfs_portmon so much, i'm leaving it up to the reader to figure out how to turn it on.

So Noel's fix is to have the client (by default) try using a non-privileged port, and if that fails with AUTH_TOOWEAK due to someone (unfortunately) having nfs_portmon turned, then it will retry the request using a privileged port (assuming the client has some available).

Technorati Tag:
Technorati Tag:
Technorati Tag:


(2005-11-14 17:02:50.0/2005-08-15 15:51:52.0) Permalink Comments [6]
Trackback: http://blogs.sun.com/erickustarz/en_US/entry/default_use_of_reserved_ports

Trackback URL: http://blogs.sun.com/erickustarz/en_US/entry/default_use_of_reserved_ports
Comments:

Can you explain why this is a good thing?

Or, more accurately, what is wrong with the current system that makes this change worthwhile?

While I agree that simply using privileged ports isn't the answer to securiy, it doesn't actually harm security, may help in some cases, and is an eminently sensible default.

I would argue against this change, as it:

  • Makes the default settings less secure - enforcing the use of privileged ports blocks potential problems
  • Makes the code more complex
  • Gives you a performance hit, as the client has to think harder and may have to sned more packets over the wire

Certainly on all my systems, nfs_portmon is enabled - and has been since as long as it's been possible to do so. In fact, what I've never understood is why having nfs_portmon turned off is still the default.

Posted by Peter Tribble on August 16, 2005 at 02:24 AM PDT #

what was the motivation for this ? why 'fix' it now ?

Posted by anon on August 16, 2005 at 02:56 PM PDT #

Ah controversy!

So the motivation for the change (i believe this answers both comments) is that we've run into situations where vague "NFS problems" were happening simply due to no more privileged ports being available. Having the client not try to use privileged ports by default fixes that. Having the client use precious kernel resources unnecessarily seems odd.

Now for admins who know what they are doing, simply enabling 'nfs_portmon' is one way of enforcing the privileged ports... a better way is real security via RPCSEC_GSS.

I believe that is the real answer here: the various NFS implementations in existence (solaris, linux, AIX, netapp, etc) are strong now and that mandating real security should be the norm.

As for perf hit, it won't matter as once the connection is established, we continue to the the privileged or non-privileged port (whatever the server mandates) - and the connection will live as long as there's active traffic.

And the only code change was flipping a 1 to 0 :)

Posted by eric kustarz on August 16, 2005 at 04:49 PM PDT #

[Trackback] Chuck Lever gave some pointers in our Linux-NFS troubleshooting. Several of our Linux servers have been experiencing NFS access issues. They enter a “hung” state and it is hard to get them back without rebooting. We do use the linux automo...

Posted by &lt;the occasional blog&gt; on August 21, 2005 at 09:17 AM PDT #

Hi Eric, Interesting post here, I notice that you reference the man page for nfsd, but do not link to it :) Are you aware that you can browse this information on docs.sun.com here</a href>? If ever you want to point folks to information that describes the 'underpinnings' of previous code decisions that you have no time to explain, a google search on the following: docs.sun.com:: RPCSEC_GSS gives this result, which enables readers to find context around your posting and gives nice visibility to the tech docs. Ideally, you could also communicate this recent code change to the man page and doc writers in this manner. Sue Weber is a former man page guru and is currently *the* place to start for information about OpenSolaris documentation. cheers, M

Posted by MissMichelle on October 03, 2005 at 04:07 PM PDT #

thanks! updated with the docs.sun.com link.

Posted by eric kustarz on October 03, 2005 at 04:27 PM PDT #

Post a Comment:

Name:
E-Mail:
URL:

Your Comment:

HTML Syntax: NOT allowed

Languages:


« November 2009
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
     
       
Today


XML



blogs.sun.com
Weblog
Login



Today's Page Hits: 326