From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: wli@holomorphy.com, cw@f00f.org, mingo@elte.hu, anton@samba.org
Subject: Re: /proc/sys/kernel/pid_max issues
Date: 12 Sep 2004 23:20:29 -0400 [thread overview]
Message-ID: <1095045628.1173.637.camel@cube> (raw)
Ingo Molnar writes:
> it's getting quite spaghetti ... do we really want to handle
> RESERVED_PID? There's no guarantee that any root daemon wont stray out
> of the 1...300 PID range anyway, so if it has an exploitable PID race
> bug then it's probably exploitable even without the RESERVED_PID
> protection.
Purpose:
1. weak security enhancement
2. cosmetic (backwards, IMHO)
3. speed (avoid PIDs likely to be used)
I'd much prefer LRU allocation. There are
lots of system calls that take PID values.
All such calls are hazardous. They're pretty
much broken by design.
Better yet, make a random choice from
the 50% of PID space that has been least
recently used.
Another idea is to associate PIDs with users
to some extent. You keep getting back the same
set of PIDs unless the system runs low in some
global pool and has to steal from one user to
satisfy another.
BTW, since pid_max is now adjustable, reducing
the default to 4 digits would make sense. Try a
"ps j" to see the use. (column width changes if
you change max_pid)
next reply other threads:[~2004-09-13 3:24 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 3:20 Albert Cahalan [this message]
2004-09-13 7:42 ` /proc/sys/kernel/pid_max issues William Lee Irwin III
2004-09-13 14:11 ` Albert Cahalan
2004-09-13 14:27 ` William Lee Irwin III
2004-09-13 14:51 ` Herbert Poetzl
2004-09-14 2:13 ` William Lee Irwin III
2004-09-23 13:13 ` Pavel Machek
2004-09-24 16:02 ` Martin Mares
2004-09-23 13:11 ` Pavel Machek
2004-09-13 7:57 ` Ingo Molnar
2004-09-13 13:54 ` Albert Cahalan
2004-09-13 14:24 ` William Lee Irwin III
2004-09-13 14:54 ` Albert Cahalan
2004-09-14 2:02 ` William Lee Irwin III
2004-09-14 15:32 ` Ingo Molnar
2004-09-18 18:32 ` Pavel Machek
2004-09-23 13:18 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2004-09-12 8:56 Anton Blanchard
2004-09-12 9:36 ` William Lee Irwin III
2004-09-12 9:51 ` Ingo Molnar
2004-09-12 9:58 ` William Lee Irwin III
2004-09-12 10:10 ` William Lee Irwin III
2004-09-12 10:13 ` Ingo Molnar
2004-09-12 10:43 ` William Lee Irwin III
2004-09-12 10:45 ` William Lee Irwin III
2004-09-12 11:08 ` William Lee Irwin III
2004-09-12 11:20 ` Ingo Molnar
2004-09-12 17:13 ` William Lee Irwin III
2004-09-12 18:02 ` Chris Wedgwood
2004-09-12 23:06 ` William Lee Irwin III
2004-09-12 9:39 ` Ingo Molnar
2004-09-12 9:43 ` William Lee Irwin III
2004-09-12 12:18 ` Arjan van de Ven
2004-09-12 12:30 ` Anton Blanchard
2004-09-12 12:44 ` Arjan van de Ven
2004-09-12 13:34 ` Anton Blanchard
2004-09-12 13:41 ` Ingo Molnar
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=1095045628.1173.637.camel@cube \
--to=albert@users.sf.net \
--cc=anton@samba.org \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=wli@holomorphy.com \
/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