This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Sun, Jan 27, 2013 at 12:06 PM, Florian Weimer <> wrote:
> * Dan Nicholson:
>> Let's just fix the problem at the source. On the first pass, avoid ports
>> that are registered in services. If no unregistered ports can be found,
>> fall back to taking the first randomly open port. On my fedora system,
>> 295 of the 541 ports between 512 and 1023 are unregistered. This should
>> avoid registered ports on most typical systems.
> BIND uses 921 and 953.  953 is also used by Unbound.  921 doesn't seem
> to be listed in /etc/services anywhere.  Fedora has 953, but Debian
> doesn't.  So the /etc/services approach does not seem particularly
> reliable.

I see your point, but isn't this just a bug in the configuration?
Shouldn't those ports just be added to services? Debian does control
the file. I don't see how that's any different than adding them to
/etc/bindresvport.blacklist except that /etc/services already exists
and has the vast majority of ports defined already.

Ignore the bindresvport issue for a moment. In this case, you have two
services that are using reserved ports that are not defined with IANA.
It seems to me that you can either add the ports to services
temporarily while working to get the ports registered with IANA, or
you can patch the packages so that they don't use reserved ports. To
me the first option seems preferable. What's the point of
/etc/services if not to describe what ports will be used by programs
on the system?

> There's a patch for another blacklist file,
> /etc/bindresvport.blacklist, which we use in Debian, but it does not
> work for some reason:
> <>
> I haven't yet found the cause of this bug.  (In the bug, "eglibc"
> refers to the Debian source package.  I don't think the patch was
> upstreamed.)

I haven't looked at that patch in detail, but the concept seems fine
to me. I'd still prefer to just use /etc/services since it already
exists everywhere nearly fully formed, and /etc/bindresvport.blacklist
seems to have entirely duplicate functionality.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]