On Tuesday April 24, [email protected] wrote:
> On Tuesday 24 April 2007 01:09, Neil Brown wrote:
> > It would be nice if the libritpc version of bindrecvport could be
> > configured to avoid some list of ports, whether from /etc/services or
> > from elsewhere.
>
> BTW, I wouldn't use /etc/services as the blacklist for bindresvport.
> The range of available privileged ports is rather tight already. If
> you exclude everything found in /etc/services, you're down to
> 249 ports in the 512-1024 range (for TCP and UDP, each). This
> will not please the 10,000 mounts crowd at Prominent CPU Vendor :)
> I really think you want to go with a separate blacklist file.
Certainly supporting a blacklist file and preferring it to
/etc/services would make sense. Using /etc/services in the absence of
a blacklist should be safe enough.
I wonder if these is something more substantial that can be done to
avoid the problems though.
I'm aware to two problems:
1/ ports that are held open for a long time (e.g. the port a server
listens on, or a port that is opened once and used occasionally
for sending messages, such as the port statd uses to talk to
lockd). These can conflict with servers which wish to bind to
assigned port numbers. We can only address this with a
black-list.
2/ tcp sockets that linger in CLOSE_WAIT thus preventing other
sockets from binding to the same address. This prevents
privilege ports being used at a high rate.
Using UDP avoid this problem but is not always acceptable.
I wonder if we could make more use of SO_REUSEADDR in
bindresvport. This would require handling an EADDRINUSE from
connect, incase we are connecting to the same host as the last
time the port was used, but if it is all in the libritpc library,
that might be quite manageable. Doing that should reduce the
pressure on privileged ports.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
At 03:24 AM 4/24/2007, Neil Brown wrote:
> 2/ tcp sockets that linger in CLOSE_WAIT thus preventing other
> sockets from binding to the same address. This prevents
> privilege ports being used at a high rate.
> Using UDP avoid this problem but is not always acceptable.
> I wonder if we could make more use of SO_REUSEADDR in
> bindresvport.
This is risky - while it allows rapid rebinding to the ports, it also
allows old duplicate packets in the network to arrive at the newly
rebound port, potentially causing it to reset and/or produce
unexpected statuses. I would not recommend this as a design
requirement!
Tom.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
At 11:15 AM 4/24/2007, Talpey, Thomas wrote:
>At 03:24 AM 4/24/2007, Neil Brown wrote:
>> 2/ tcp sockets that linger in CLOSE_WAIT thus preventing other
>> sockets from binding to the same address. This prevents
>> privilege ports being used at a high rate.
>> Using UDP avoid this problem but is not always acceptable.
>> I wonder if we could make more use of SO_REUSEADDR in
>> bindresvport.
>
>This is risky - while it allows rapid rebinding to the ports, it also
>allows old duplicate packets in the network to arrive at the newly
>rebound port, potentially causing it to reset and/or produce
>unexpected statuses. I would not recommend this as a design
>requirement!
OBTW - I assume you mean TIME_WAIT not CLOSE_WAIT...
SO_REUSEADDR can't seize a port used by a socket in CLOSE_WAIT
because the kernel is waiting for the local file descriptor to be
closed. IOW, this is a different problem, and should be short
lived, provided that the process that owns the fd is running.
There are also such problems as FIN_WAIT_2, which are even
harder to escape from. Bottom line, better to avoid overloading
privileged ports as a protection mechanism here, and instead
strengthen the portmap/rpcbind registration as mentioned before.
Tom.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs