PID of client requirements

[Marcus Brinkmann]

Hi,

in a couple of places, notably POSIX record file locking and POSIX shared
memory (or semaphores, sorry, I forgot), we need the PID of the client.

Thomas said before that it is good enough to let the client report its PID
in the RPC.  I think the argument was something like that only POSIX
programs are required to behave correctly, and that all POSIX programs will
use the C library, which will do the right thing and provide the current PID
of the calling process in the RPC.

It is clear that all POSIX programs will behave correctly given that
semantic.  What is not clear to me is if this is safe against malicious
abuse.

Let's start with an example.  Imagine a privileged program that relies on the
GETLK function to see what the current holder of a lock is and which kills
that process in some situations.  Then everybody who could take the lock would
be able to have any process (including the root filesystem etc) killed just by
providing the PID of that process when getting the lock.  The ability to take
a shared lock requires only read permission.  Now, one could say that if you
rely on locking, you should not leak any read or write permission to the
lockfile, and it seems that programs are generally careful enough about
that.  Here is an example:

ulysses:/tmp# ls -l /var/lib/dpkg/lock
-rw-r-----    1 root     root            0 2002-10-08 20:50 /var/lib/dpkg/lock

The general question is:  Are there any potential security concerns about having
the caller provide the PID?  The above example is surely safe, because no
untrusted party should have read or write permission.  This seems to be
generally true for record locks.  I have not investigated the other
application (shared memory and/or semaphores) where PID knowledge is
required.  Has anybody?

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/