Re: proc/sys/sunrpc/max_resvport

["Brian J. Murrell" <brian@interlinx.bc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 1852 bytes --]

On Tue, 2007-10-09 at 19:43 -0400, Trond Myklebust wrote:
> 
> There are two ports involved in an IP connection: one source port (i.e.
> the client) and one destination port (i.e. the server). If bind() is run
> on a socket that was set up by the client, it will set the source port
> for the connection.

I see where this is going.  I had not considered that one might want to
set a range of ports that the client uses.

> The reason why an RPC client would want to select a particular port
> number is that for most *NIX setups, the ports with number < 1024 will
> usually require root privileges to bind() to.

Indeed.  The insecurity of putting (even a tiny amount of) trust in a
remote application using a port < 1024 aside.  :-)

> By requiring that RPC
> calls must originate from such a 'privileged port', an NFS server can
> therefore make it slightly harder for an unprivileged process on that
> machine to spoof NFS requests.

Sure.

> See the 'secure' and 'insecure' export options on 'man 5 exports'.

Yeah.  I'm familiar with them.  I had just not drawn the link from that
to this sysctl being for limiting the client bind address.

> Not really. portmap doesn't choose the port numbers: the server
> processes themselves choose that number, and so they are the ones that
> you need to fix up.

Hrm?  Really?  I thought the process of registering an RPC server with
the port mapper involved the port mapper finding an available port for
it to run on.  I thought that was whole point of the port mapper -- to
allocate ports out of a "limited" pool of available ports for services
that wanted to be available -- rather than the more traditional
"officially assigned port"-from-IANA method of getting a port number.

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs