Use reserved port only when required for NIS look-ups

[Honza Horak]

Hi all,

we have a request from user [2] to use reserved port only when required 
for NIS look-ups. This is the case we need to address:

When non-root user asks NIS server for any information, unprivileged 
port is used on client side, so there are enough ports to use. However, 
when root asks NIS server for any information, reserved port is used 
every-time. Having a client with many look-ups with root privileges we 
can get to a state where all reserved ports are exhausted and some other 
services that need to bind to a reserved port can eventually fail.

One ancient discussion about limited reserved ports count with regards 
to well-known ports is available at [1], but this is something different.

This is reason why we can't simply use unprivileged ports for all look-ups:

NIS server is able to be "secured" with a configuration, where 
administrator marks some maps as "secure" (basically maps with 
passwords) and only connections form a reserved port are served in that 
case. So if we used non-reserved ports for all look-ups, some of them 
wouldn't be served.

HP's solution to address this is described like as follow:

"Reserved ports are the ports from 0 to 1024. Only root users can bind 
to these ports. In previous releases, NIS commands attempted to bind to 
reserved ports by default. If there are numerous client requests, all 
the reserved ports can be consumed. This version of NIS enables binding 
to reserved ports for select commands or daemons when accessing secure 
maps which results in reduced usage of reserved ports by NIS. This 
change does not compromise performance or security."

I'd like to propose a similar behavior, ie. to limit use of reserved 
ports only for "secured maps" requests. The problem is, that client 
currently doesn't know which maps are marked "secured" on the server. 
Because of that we'd have to introduce a new client-side configuration 
option or environment variable (used in a patch attached) to define 
secure maps on client side. That configure option could default to 
"all", which would mean the same as the current behavior.

I'm not aware of any security implications that would be introduced by 
using unreserved ports, but I'm not a security expert.

Any comments/suggestions?

Cheers,
Honza

[1] http://sourceware.org/ml/libc-alpha/1999-06/msg00079.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=689424
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-resport.patch
Type: text/x-patch
Size: 3162 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120810/0e188ca1/attachment.bin>