On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote:
> I see you don't remember the original post. It argued in
> favor of a large PID space "because the output of ps wouldn't
> look nice otherwise"!!! (the poster wanted output sorted by
> start time without using --sort=start to ask
David Weinehall writes:
> On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote:
>> Andries Brouwer writes:
>>> On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:
What do you think of "ps -efj" on a standard 80x24 screen?
>>>
>>> I never give such commands, but ju
On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote:
> Andries Brouwer writes:
> > On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:
>
> >>> My machines regularly see 6- or 7-digit PIDs.
> >
> >> Oh, the horror!
> >>
> >> Consider, do you like to type "kill 12345678
Andries Brouwer writes:
> On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:
>>> My machines regularly see 6- or 7-digit PIDs.
>
>> Oh, the horror!
>>
>> Consider, do you like to type "kill 1234567890" more than
>> a simple "kill 1234"?
>
> Hmm. I double click on the ps output and
On Sat, Sep 30, 2000 at 08:35:28AM -0500, Jeff Epler wrote:
> 31- or 32-bit PIDs might be a convenience, but they don't furnish
> security against wraparound attacks, they just make them take
> a little longer to exploit.
Precisely. It takes a factor 6 longer.
Maybe you think security is a
On Fri, Sep 29, 2000 at 11:44:42PM +0200, Andries Brouwer wrote:
> There are a few weaknesses that can be exploited using a wraparound.
> With 100 processes/sec that takes 497 days with a 32-bit pid
> and 5 minutes with a 16-bit pid.
Surely the estimate of 100 forks/sec is low. I get 83 forks/se
On Fri, Sep 29, 2000 at 06:51:22PM -0400, Chris Wing wrote:
> > (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
> > is used for the fields msg_lspid and msg_lrpid of the (obsolete)
> > struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
> > struct shm
Andries:
Just to clarify, the old struct msqid_ds et. al are still used by all
Linux software before glibc 2.2. As of glibc 2.2, there is a new
user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides
32-bit pids and 32-bit uids. All software using SysV IPC will need to be
recom
On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:
> > The code is old.
> > There is very little reason for it, and we could change today.
> > My machines regularly see 6- or 7-digit PIDs.
> Oh, the horror!
>
> Consider, do you like to type "kill 1234567890" more than
> a simple
Andries Brouwer writes:
> On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote:
> The code is old.
> There is very little reason for it, and we could change today.
Some userspace software uses "short" for PIDs. Bash did this.
> In fact I think I once submitted the corresponding patch
On Fri, Sep 29, 2000 at 09:17:11AM +1200, Chris Wedgwood wrote:
> [The patch is available. There are a few security advantages.
> Also, it makes a fork a just measurable fraction of a percent
> faster.]
>
> How does it make it faster? The only thing I can see is it might
> remove th
On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote:
> looking at my process list after a week or so of uptime I discoverd that PIDs
> seem to wrap around at 32767 (aka. 2^15 - 1).
Yes.
> I find this "feature" annoying, since I like to view my process list sorted
> by PID, which giv
Hi,
looking at my process list after a week or so of uptime I discoverd that PIDs
seem to wrap arround at 32767 (aka. 2^15 - 1).
I found the relevant code doing this in kernel/fork.c:get_pid() where a mask
(0x8000) is used to limit the PID of a new process to 15 significant bits.
(I am runni
13 matches
Mail list logo
