linux-kernel - Re: [patch 016/104] epoll: introduce resource usage limits

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090128053642.GL5038@1wt.eu>
Date:	Wed, 28 Jan 2009 06:36:43 +0100
From:	Willy Tarreau <w@....eu>
To:	Greg KH <gregkh@...e.de>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Bron Gondwana <brong@...tmail.fm>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Theodore Ts'o" <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>
Subject: Re: [patch 016/104] epoll: introduce resource usage limits

On Tue, Jan 27, 2009 at 09:26:30PM -0800, Greg KH wrote:
> On Tue, Jan 27, 2009 at 08:10:41PM -0800, Davide Libenzi wrote:
> > In my servers, I know if they are going to be loaded, and I bump NFILES 
> > (and a few other things) to the correct place. Since many of those 
> > limits do not actually pre-allocate any resource, I don't need to wait and 
> > monitor the values, before taking proper action.
> 
> But what about people who want to know what the current usages are, so
> that they _can_ monitor things and adjust them on the fly if things are
> about to go boom?
> 
> I see no reason why we can't leave the value where it is today, and add
> the ability to both turn the limits off entirely, and also report our
> current usage.  That keeps the DOS from happening on "default" systems,
> and lets admins have an idea if they need to bump up the values on their
> systems as well.
> 
> I don't understand your objection to allowing the usage to be monitored.

Agreed. If sysadmins get trapped by the upgrade, the fix for an
hypotethical DoS is a 100%-certain DoS by itself. The general sense
that "if it's not broken, don't fix it" applies here as well. The
server's sysadmin should not be bothered by a security upgrade (anyway,
after a few minutes of havoc in prod, he will revert to previous version
without trying to understand any further). But the campus sysadmin having
trouble with local users already spends a lot of time tweaking limits.
Now we offer them a new limit they can tune, they'll happily use it.
Anyway, even at 128 they'll probably lower it down a lot. So basically
we're with a medium value which does not fit any usage.

Willy

--
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/