proc/sys/sunrpc/max_resvport

proc/sys/sunrpc/max_resvport

[Brian J. Murrell]

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

I've been trying to link /proc/sys/sunrpc/max_resvport to the process
the portmapper uses to allocate ports from but have not found it.  So
perhaps somebody here can answer what I hope is a simple question.

Can /proc/sys/sunrpc/max_resvport be used to limit (the upper bound of)
the port range that the portmapper will allocate for all RPC servcies?
If I set it to, say, 900, I can be guaranteed that no RPC servers will
get bound to ports > 900?

Thanx,
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

Re: proc/sys/sunrpc/max_resvport

[Trond Myklebust]

On Tue, 2007-10-09 at 13:12 -0400, Brian J. Murrell wrote:
> I've been trying to link /proc/sys/sunrpc/max_resvport to the process
> the portmapper uses to allocate ports from but have not found it.  So
> perhaps somebody here can answer what I hope is a simple question.
> 
> Can /proc/sys/sunrpc/max_resvport be used to limit (the upper bound of)
> the port range that the portmapper will allocate for all RPC servcies?
> If I set it to, say, 900, I can be guaranteed that no RPC servers will
> get bound to ports > 900?

No. The portmapper is a userland process and has nothing to do
with /proc/sys/sunrpc/max_resvport.

The latter controls the kernel's sunrpc client port usage _only_.

Trond


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: proc/sys/sunrpc/max_resvport

[Brian J. Murrell]

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

On Tue, 2007-10-09 at 16:57 -0400, Trond Myklebust wrote:
> 
> No. The portmapper is a userland process and has nothing to do
> with /proc/sys/sunrpc/max_resvport.

No wonder I couldn't find the linkage.  :-)

> The latter controls the kernel's sunrpc client port usage _only_.

Hrm.  So that would mean only kernel space rpc services, like nfsd?

I guess there is no way to limit the userspace portmapper the way
max_resvport does for the kernel rpc services then?

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

Re: proc/sys/sunrpc/max_resvport

[Trond Myklebust]

On Tue, 2007-10-09 at 17:01 -0400, Brian J. Murrell wrote:
> On Tue, 2007-10-09 at 16:57 -0400, Trond Myklebust wrote:
> > 
> > No. The portmapper is a userland process and has nothing to do
> > with /proc/sys/sunrpc/max_resvport.
> 
> No wonder I couldn't find the linkage.  :-)
> 
> > The latter controls the kernel's sunrpc client port usage _only_.
> 
> Hrm.  So that would mean only kernel space rpc services, like nfsd?

The client processes only. IOW: the nfs client, lockd client and the
posix acl client.

> I guess there is no way to limit the userspace portmapper the way
> max_resvport does for the kernel rpc services then?

Not as far as I know.

Cheers
  Trond


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: proc/sys/sunrpc/max_resvport

[Brian J. Murrell]

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

On Tue, 2007-10-09 at 17:09 -0400, Trond Myklebust wrote:
> 
> The client processes only. IOW: the nfs client, lockd client and the
> posix acl client.

I'm sure I'm missing something obvious here, but isn't it the server
that (chooses and) binds to a port?  What effect does a "max port" have
on a client when it has to bind to the port the server chose/was given?

> Not as far as I know.

Pity.

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

Re: proc/sys/sunrpc/max_resvport

[Trond Myklebust]

On Tue, 2007-10-09 at 17:26 -0400, Brian J. Murrell wrote:
> On Tue, 2007-10-09 at 17:09 -0400, Trond Myklebust wrote:
> > 
> > The client processes only. IOW: the nfs client, lockd client and the
> > posix acl client.
> 
> I'm sure I'm missing something obvious here, but isn't it the server
> that (chooses and) binds to a port?  What effect does a "max port" have
> on a client when it has to bind to the port the server chose/was given?

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.

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. 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.
See the 'secure' and 'insecure' export options on 'man 5 exports'.

> > Not as far as I know.
> 
> Pity.

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.

Trond


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: proc/sys/sunrpc/max_resvport

[Brian J. Murrell]

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

Re: proc/sys/sunrpc/max_resvport

[Trond Myklebust]

On Wed, 2007-10-10 at 11:10 -0400, Brian J. Murrell wrote:
> > 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.

Nope. The job of the portmapper is only to _publish_ those port numbers
once the server has selected them.
That way an rpc client needs only to know the server IP address, the
port number on which rpc.portmap is running (port number 111), and the
RPC program number (see /etc/rpc) for the service it is trying to use.

Cheers
  Trond


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: proc/sys/sunrpc/max_resvport

[Brian J. Murrell]

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

On Thu, 2007-10-11 at 09:44 -0400, Trond Myklebust wrote:
> 
> Nope. The job of the portmapper is only to _publish_ those port numbers
> once the server has selected them.

Ahhhh.  I see now.

> That way an rpc client needs only to know the server IP address, the
> port number on which rpc.portmap is running (port number 111), and the
> RPC program number (see /etc/rpc) for the service it is trying to use.

Indeed, this I understood.  I just misunderstood who selected the ports
for the server.

Thanx for all the info!

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