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

[Jeff Law <law at redhat dot com>]

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.

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.

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

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

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.

jeff