netdev - Re: [RFC Patch] net: reserve ports for applications using fixed port numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201002041444.01897.opurdila@ixiacom.com>
Date:	Thu, 4 Feb 2010 14:44:01 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Cong Wang <amwang@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
	Neil Horman <nhorman@...driver.com>,
	linux-sctp@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [RFC Patch] net: reserve ports for applications using fixed port numbers

On Thursday 04 February 2010 05:23:38 you wrote:

> > I think it might be useful to allow setting individual ports as reserved,
> > not only ranges, for example by using a bitmap.
> 
> This is a good idea, but I am not sure if this will be overkill? :-/
> Also, using bitmap is not friendly to sysctl interface, I am afraid.
> 

My concern is that we can have multiple applications that require a fixed port 
and if those ports are significantly apart we will decrease the port range 
available for connect. And that will hurt the rate of which new connections 
can be opened.

As for the sysctl interface I agree, I don't think it is even possible to  
cleanly use a bitmap through sysctl.

The options I see are either enhance sysctl to support bitmaps or use a 
dedicated /proc/net entry. 

I want to give this a try, which one do you people think is better?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html