Messages in this thread | | | Date | Tue, 27 Sep 2005 21:20:48 +0400 | From | Solar Designer <> | Subject | PID reuse safety for userspace apps (Re: [linux-usb-devel] Re: [Security] [vendor-sec] [BUG/PATCH/RFC] Oops while completing async USB via usbdevio) |
| |
[ 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |