Why wrapping PIDs is evil [was 32bit]

From: Pavel Machek (pavel@suse.cz)
Date: Fri Jan 14 2000 - 16:11:21 EST


Hi!

> > a) It is easy - easier than the change to larger uid.
> > Roughly speaking the only change is in the ipc structs.
> > (The other part of the change is in /proc.)
>
> Do libc5 and glibc give the illusion of a 32bit pid - I thought they didnt
>
> > b) The reuse of pids causes security problems.
>
> No.. people cause security problems.

Sorry, alan. No. Unix is broken with this part.

You want to kill this emacs:

pavel 209 1.6 5.2 5468 3212 3 S 22:03 0:00 emacs /tmp/mutt-bug-2

How do you do it?

kill -9 209?

But that's wrong. Pavel may have seen you are going to kill his emacs
and may have wrapped pids, killed his emacs himself, and you are now
killing _your_ netscape you've just ran.

kill -STOP 209; ps -aux | grep 209; kill -9 209

Is also no good, pavel could kill -9 it himself.

I'm currently searching for ways for process to be only able to kill
processes it spawned (it is part of sandbox). There's no way to do it
safely. Every time you have

kill( nonzero, )

in program, there's security problem in there. [The only exception
might be when you are killing process you are parent of, and I'm not
sure it is exception.] Yes, it is unlikely.

Alan, I'm searching for ways to safely kill the process (something
like "I want to kill process #209, started 13:25. Given it is at least
13:26, it is unique :-), but I see none.
                                                                Pavel
PS: Oh, you can kill pavel's emacs safely by su pavel -c 'kill -9
-1'. But that kills also lots of innocent processes...

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:26 EST