From: David Bein <d.bein@f5.com>
To: <linux-kernel@vger.kernel.org>
Subject: Re: /proc/sys/net/ipv4/ip_local_reserved_ports
Date: Fri, 16 Sep 2011 00:21:36 -0400 [thread overview]
Message-ID: <4E72CED0.1020200@f5.com> (raw)
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.
reply other threads:[~2011-09-16 4:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E72CED0.1020200@f5.com \
--to=d.bein@f5.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox