Re: PID of client requirements

Marcus Brinkmann <[email protected]> writes:

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

Trusting the user to provide his pid is only half of the job when
signals are concerned.  The second thing needed is a signal
authorization port which the user requests from the server, and which
the server will provide in the signal message.  See, for example, how
this works for terminals.

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

You are right to be thinking about this.