Reserved network ports [LWN.net]

Reserved network ports

Posted Feb 26, 2010 13:56 UTC (Fri) by hppnq (guest, #14462)
In reply to: Reserved network ports by dlang
Parent article: Reserved network ports

how would you implement this in userspace without having to change every program (that uses ephemeral ports) on the system? Remember to include closed source and staticly linked programs in your solution.

Just to be clear: you need to reliably bind a specific fixed address in the ip_local_port_range to a socket, where a multitude of other processes may be competing for the same resource. If it is impossible to do this using whatever configuration options the software offers to move the desired port out of ip_local_port_range, or by starting it early enough, or through the use of another layer like inetd or a proxy and/or NAT, I wouldn't rule out admitting defeat and moving it to its own interface or even (virtual) system.

The measures mentioned here need to be considered anyway unless you have good reasons to assume that no other process will attempt to bind(reserved_port), and in any case it seems a bit more reasonable to expect software to honour the concept of an ephemeral port than it is to expect a kernel to facilitate programs that completely ignore it.

Of course, only a fool would run an important service on a fixed ephemeral port without taking additional measures to make sure it is actually the intended service handling the communication.

So to me, the more interesting question would be: what would you do if you had more than one of those programs you mention using the same fixed port number?

(Log in to post comments)

Reserved network ports

Posted Feb 26, 2010 18:29 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

no, the issue here is when one program wants to bind to a specific port in the ip_local_port_range only to find out that another program was allocated that port when it had no preference and told the kernel to allocate a port for it.

if you have multiple programs attempting to explicitly use the same port you have problems, but there should be no reason for the explicitly bound ports to conflict with kernel allocated ports.

Right now ip_local_port_range is a single range of ports. This patch allows the admin of the box to tell the kernel to skip over specific ports in that range. This effectivly makes ip_local_port_range be a list of ranges rather than a single range.

the problem is that right now there _are_ no 'additional measures' that a sysadmin can take to make sure that ephemeral port requests don't get this port other than just narrowing the range of available ports to not include that port, but that can drasticly cut the number of ephemeral ports available to the system.

In the cases where I have two services that need to use the same port I add a second IP address to the interface and bind one service to each IP address. but that isn't the case that these patches are addressing.

Reserved network ports

Posted Feb 26, 2010 19:29 UTC (Fri) by mrshiny (subscriber, #4266) [Link]

Exactly. The problem is that there are already programs which expect to use certain "ephemeral" ports as a well-known listening port. You can't close your eyes and wish that away. With this patch the "ephemeral ports" list gets smaller and more configurable.

Seems like an obvious improvement to me with no obvious downside.

Sure there are other problems not addressed by this patch, but I feel it _is_ progress. Heck, just put all the ports in /etc/services in here and you're already off to a good start.

Reserved network ports

Posted Feb 27, 2010 14:39 UTC (Sat) by nix (subscriber, #2304) [Link]

But I want to be able to close my eyes and wish NFS away!

For a while it looked like POHMELFS was just the thing: a faster better
more reliable distributed NFS, with pretty much the same system
administration model ('oops, I want to make this FS networked, bang,
done'). But now Evgeniy has started to move POHMELFS to this elliptics
cloud-based thing, and as far as I can tell this requires you to *recreate
the filesystem* when you want to POHMELFSize it.

I don't *have* a cloud. I have one or two great big servers and I want to
distribute stuff between them and export their filesystems, possibly at
short notice, to a bunch of clients. And NFS is slow and inefficient and
non-POSIX and generally nasty.

Is there anything better? For a while it looked like POHMELFS would be,
but I no longer know. I've been hoping for something better for a couple
of decades now...

Reserved network ports

Posted Feb 28, 2010 22:18 UTC (Sun) by hppnq (guest, #14462) [Link]

I was thinking of things like ypbind, which does not do a bind(0), but generates its own "random" port, and it will grab that port if you don't do anything in userspace to prevent it. I'm perfectly aware that this is not the case that is intended to be addressed by this patch. But if you want to solve this problem, why not the one that is addressed by the patch?

I must be starting to sound like I have something against this patch, which is not the case, so I'll drop it here.

Reserved network ports

Posted Mar 1, 2010 1:14 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

huh, I wasn't aware that there was software out there that did that sort of thing. I see the fix for this being fairly simple, change misbehaving programs like ypbind to either use fixed, configurable ports, or if they don't care, do bind(0) (or just don't run them on any system you want to be reliable ;-)