This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't bind to registered ports in bindresvport
On Tue, Jun 5, 2012 at 2:57 PM, 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.
>
> 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.
The currently proposed fix for glibc is an additional heuristic that
slows down bindresvport but provides some protection against the
behaviour of stealing ports for described services. Thus allowing the
distribution or maintainer to manage /etc/rpc in order to provide
protection against service port conflicts when using the bindresvport
API. If managed properly it should solve a lot of headache.
Unfortunately on a system with *lots* of dynamically enabled and
disabled services it doesn't solve the problem.
You *need* a higher level understanding of the problem. You need to
detect that a daemon is using the port you need and have the services
manager use the dependencies to start and stop services in such a way
that it results in a working system.
Cheers,
Carlos.