Re: [PATCH] Don't bind to registered ports in bindresvport

[Dan Nicholson <dbn dot lists at gmail dot com>]

On 6/5/12, Jeff Law <law@redhat.com> wrote:
> On 06/04/2012 09:25 AM, Dan Nicholson wrote:
>
>>> http://sourceware.org/glibc/wiki/MAINTAINERS#Distribution_Maintainers
>>
>> I've added him and Jeff Law since I know this has been an issue for both
>> distros. Here's the fedora bug again:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=103401
>>
>> And here's the patch their using on Debian/Ubuntu currently to work
>> around the issue (header says it originates from OpenSUSE):
> It's definitely a problem.  103401 has enough state to get a sense of
> the issue.
>
> I haven't looked at this for a while as the current plan didn't require
> further action from me.
>
> Specifically for RHEL6 and older we were in the process of auditing the
> major daemons to ensure they use portreserve.  While that's far from an
> ideal solution (it's race prone and doesn't work well for daemon
> restarts), it was deemed the best of a set of bad solutions.

Right, this is specifically the hack I think should go away.

> For RHEL7 and beyond we're planning to use capabilities within systemd
> to reserve ports.  It's a step forward, but still far from ideal.

Definitely an improvement since systemd can reserve the ports more
cleanly than an out of band process like portreserve, but still you're
just plugging holes, IMO.

> Checking /etc/rpc every time something wants to open a rpc port might
> get rather expensive and many ports are going to be avoided even though
> those services aren't running.

It's actually /etc/services, but I don't think this is really
expensive in the context. Since this is part of nss, it should
essentially be grabbed from a static buffer in libc. In a call to ask
libc to bind a reserved port for you, I don't think it's unexpected
that it will query some part of nss.

> If someone installed an /etc/rpc with
> reservations for every port in the IANA database where wouldn't be too
> many ports left for bindresvport to use.

Originally I did write it that way, but Carlos suggested to change so
that if all the ports are registered that it fall back to just
grabbing the first open port. That's what the current patch does.
There are actually 4 phases:

1. Check between 600 & 1023, skipping open ports and ports registered
in services
2. Check between 512 & 599, skipping open ports and ports registered in services
3. Check between 600 & 1023, skipping open ports
4. Check between 512 & 599, skipping open ports

If you get all the way through that, you'll get EADDRINUSE.

> We were looking at white/black lists of ports when we were pondering
> fixing this in glibc itself.

Here I'm considering /etc/services as the black list. Maintaining a
separate black list seems like it would eventually just become
services given enough time. It's just a matter of time until someone
files a bug asking to reserve 674 for acap or whatever. :) IMO, if you
want a reserved port in the lower range, you get it in services.
That's what it seems to be there for.

> However, I'll welcome this approach as just about anything would be
> better than the current status quo.
>
> And for those who think everything needing a port between 600 & 1023
> should start before that rpc services, that's just not feasible in the
> real world.

Definitely agree with that.

--
Dan