linux-kernel - Re: [PATCH 2/4] posix-timers: limit the number of posix timers per process

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: <20110830152216.dffd3cc3.akpm@linux-foundation.org>
Date:	Tue, 30 Aug 2011 15:22:16 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	eric.dumazet@...il.com
Subject: Re: [PATCH 2/4] posix-timers: limit the number of posix timers per
 process

On Tue, 30 Aug 2011 15:06:30 -0700
Andi Kleen <ak@...ux.intel.com> wrote:

> 
> > Sorry, it should be an rlimit from day one, IMO.
> >
> 
> Ok.
> 
> > Partly because rlimits are a better implementation.
> 
> The reason I went with a sysctl is that rlimits are more intrusive for 
> user space,
> requires special tools or patching bash.

Yes, deployment for new rlimits is a big PITA.  It would be sensible to
modify the shells to take some anonymous numeric argument, so you could
do

	ulimit 42 1000

to set rlimit number 42 if your shell version doesn't understand the
symbolic representation of more recent additions.  Who do I call?

There was code floating about which would permit rlimits to be modified
from other processes, perhaps by making /proc/pid/limits writable.  I
don't think it got merged.  I have a vague feeling that this might be
my fault.

> > Partly because once rlimits are added, the /proc knob no longer has any
> > sane behaviour.  Does it only modify /sbin/init?  Does it do a global
> > process walk, modifying all threads?
> 
> There's no way to modify: you would need to kill the process or randomly
> take timers away. The limit only applies to new timers.

Sure, it applies to new timers.  My concern is: what does a write to
the old /proc knob _do_?  Modify all the system's task_struct.rlim[],
overwriting whatever was there?  Something else?  It would need to at
least roughly emulate the old behaviour.

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