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]

[ I am changing the topic somewhat, so I've trimmed the CC list and
adjusted the Subject. ]

On Tue, Sep 27, 2005 at 08:52:06PM +0400, Sergey Vlasov wrote:
> (Why they did not make a kind of "file descriptor" for processes...)

Actually, I made a proposal back in 1999 which I think would let many
userspace apps deal with PID reuse nicely.

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).  The
original posting and subsequent thread can be seen here:

http://lists.nas.nasa.gov/archives/ext/linux-security-audit/1999/08/msg00108.html

The proposal itself (unedited since 1999, but the idea holds) is as
follows:

in task_struct:
	int locked_pid;

int sys_lockpid(int pid)
{
	int old;

	old = current->locked_pid;
	current->locked_pid = pid;

	return old;
}

on kill(2) and ptrace(2):
	if (pid > 0 && -pid == current->locked_pid)
		return -ESRCH;

on execve(2):
	current->locked_pid = 0;

on fork(2), in get_pid(), where last_pid is the PID being allocated:
	for_each_task (p)
		if (p->locked_pid == last_pid) p->locked_pid = -lastpid;

in applications, such as killall(1):
	do {
		lockpid(target);
		if (!need_to_kill(target)) break;
		if (kill(target, SIGKILL) == 0) break;
	} while (errno == ESRCH);
	lockpid(0);

Performance can be improved by maintaining a global locked_pid_count,
so that fork(2) could skip the loop if count is zero.  Implementing
this would require an extra spinlock (the pseudo-code above will need
some anyway, if actually implemented).

It is possible to clear locked_pid in kill(2) and ptrace(2), but I'm
not sure whether that's a good idea, as we could have these syscalls
in signal handlers that are not aware of the new feature.

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