[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PID of client requirements

From: Marcus Brinkmann
Subject: PID of client requirements
Date: Mon, 4 Nov 2002 14:23:00 +0100
User-agent: Mutt/1.4i


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

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?


`Rhubarb is no Egyptian god.' GNU    address@hidden
Marcus Brinkmann              The Hurd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]