This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Don't bind to registered ports in bindresvport
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Dan Nicholson <dbn dot lists at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 31 May 2012 13:16:01 -0400
- Subject: Re: [PATCH] Don't bind to registered ports in bindresvport
- References: <20120531153241.GA21672@buster.dwcab.com>
On Thu, May 31, 2012 at 11:32 AM, Dan Nicholson <firstname.lastname@example.org> wrote:
> When bindresvport binds to a random port, there's a good chance it will
> pick one already registered in services. That's bad since the point of
> services is to define well known ports so random programs know which
> ones to avoid. The current behavior causes lots of downstream bugs and
> requires hacky solutions like running programs early in boot to bind to
> desired ports and handing them off when the actual services start.
> Let's just fix the problem at the source. On my fedora system, 295 of
> the 541 ports between 512 and 1023 are unregistered. There's plenty of
> space to pick a smarter port. If there are systems that require more
> random ports than that, bindresvport is probably not the right API to
> 2012-05-31 ?Dan Nicholson ?<email@example.com>
> ? ? ? ?* sunrpc/bindrsvprt.c (bindresvport): Before binding the port,
> ? ? ? ?make sure it's not registered in services.
This is an application management issue that needs to be handled by
If a service depends on a port between 600-1023 then it must be
started before *any* services that randomly use ports in that range
e.g. via bindrsvprt.
Your patch attempts to encode a loose dependency via a modification to
the behaviour of the implementation and that is unacceptable.
The dependency must be expressed at a higher level e.g. while managing
A more acceptable patch might:
* Attempt to find a port for which a service is *not* reserved.
* If no such port is found then fallback to the old behaviour.