Use reserved port only when required for NIS look-ups

[Jeff Law]

On 08/10/2012 07:22 AM, Honza Horak wrote:
> 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.
Certainly using privileged ports when they're not strictly necessary is 
a problem.  Both in terms of being unable to get one when it's needed 
and in terms of grabbing a reserved port that prevents another service 
from running.

Not being familiar with the development history behind YP, is there a 
particular reason why privileged ports were always used for lookups from 
processes with root privs?



> One ancient discussion about limited reserved ports count with regards
> to well-known ports is available at [1], but this is something different.
Agreed.  FWIW, there's been some talk of a whitelist/blacklist to deal 
with that particular problem.

> 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.
Understood.  Presumably there's no way for the client to get that 
information from the server?

>
> 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."
Just to be clear, this is what HP did for HPUX11, right?  They're really 
looking for glibc to do something similar for Linux.

How did they handle the client side configuration for hpux11?  Did we 
ever get information from HP about that?

>
> 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'd tend to think a configuration file would be better than an 
environment variable, but that IMHO is a fairly small implementation 
detail if the glibc maintainers can agree to the basic idea behind this 
patch.


As far as the patch itself:
+
+      if ((res = __get_clnt_socket(&clnt_sock, &clnt_sin, inmap)) != 
YPERR_SUCCESS)
+        return res;

Do you have the test inverted here?  Don't you want to return "res" for 
YPERR_SUCCESS?


Jeff