[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4E72CED0.1020200@f5.com>
Date: Fri, 16 Sep 2011 00:21:36 -0400
From: David Bein <d.bein@...com>
To: <linux-kernel@...r.kernel.org>
Subject: Re: /proc/sys/net/ipv4/ip_local_reserved_ports
For the reserved port bitmap to be truly useful, there needs to be a way to
have the kernel bind (+ implicit bind in connect, datagram sendmsg, etc)
be told to use a "privileged" port range.
Has anyone ever considered adding the IP_PORTRANGE socket option
which would add 2 other port ranges: LOW (privileged -- e.g. 600-1023)
and HIGH (for high end ports, e.g. 55000-65535) for running around
firewalls.
This interface was added to FreeBSD maybe 15 years ago and in practical
terms means that glibc bindresvport() would select the privileged port
range,
set sin->sin_port to 0 and lets the kernel do the rest. Similar dance
for AF_INET6.
This does require tweaking glibc bindresvport() to handle the details.
The FreeBSD folks have the details in their versions of libc.
It is in fact faster because in the presence of a number of busy ports
the overhead of a few hundred bind() system calls is eliminated.
The kernel is very good at picking free ports, so this is just extending
where it does it without hacking ip_local_port_range to include
privileged ports (which IMO is a very bad idea).
I've prototyped the kernel ip socket option support for IP_PORTRANGE
(along with the sysctl glue for 2 more port ranges).
Using this and ip_local_reserved_ports, it is indeed possible to use
the reserved ports set in the bitmap and prevent all the usual problems
when some program innocently picks a privileged port that some other
daemon will expect to be free for a specific binding on a well known port.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists