Re: PID of client requirements

[Neal H. Walfield]

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

Ahem, I think you are missing the point.  We are assuming two
processes: a manager and a rogue.  The rogue process locks the file
supplying a fake pid and then blocks.  The manager process sees that
the file is locked for "too long" (define liberally) and kills the
locking process--or rather, what it thinks is the locking process.  If
the manager is running as root, this could be anyone.