lkml.org 
[lkml]   [2005]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPID 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/

\
 
 \ /
  Last update: 2005-09-27 19:24    [W:0.129 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site