Re: PID reuse safety for userspace apps (Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio)

[Solar Designer]

Perhaps I should have dropped the old Subject completely, despite the
topic I brought up being related to what was discussed.  I am talking
about PID reuse related issues in userspace apps that appear to require
an additional kernel interface to be resolved.

On Tue, Sep 27, 2005 at 09:34:11PM +0100, Alan Cox wrote:
> On Maw, 2005-09-27 at 21:20 +0400, Solar Designer wrote:
> > The idea is to introduce a kernel call (it can be a prctl(2) setting,
> > although my pseudo-code "defines" an entire syscall for simplicity)
> > which would "lock" the invoking process' view of a given PID (while
> > letting the PID get reused - so there's no added risk of DoS).
> 
> You can solve it just as well in kernel space without application
> changes.

Not really.  For example, the kernel currently has no idea, and no
reliable way to find out, that killall(1) has taken note of a PID and is
about to kill it.

> Given a refcounted structure something like
> 
> 	struct pidref {
> 		atomic_t ref;
> 		struct pidref *next, *prev;
> 		pid_t pid;
> 	};
> 
> and a hash you can take a pid reference whenever you hang onto a pid in
> kernel space and check what should be a tiny if not empty hash in the
> normal cases whenever you allocate a pid.

That would work for certain in-kernel issues.

If we would let userspace apps lock PIDs like that, there would be added
DoS risk that would need to be dealt with (e.g., by letting a process
lock only one other PID - provided that the PID space is sufficiently
large that having a half of it locked is not a problem).  But I do not
see a reason to go for that complexity.  My proposal avoids it.

(A hash table could be used along with my proposal as well to speed
things up, but it would not affect _allocation_ of PIDs.  Rather, only
the "locking" process's view would be affected by the "lock".)

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