Re: PID of client requirements

[Thomas Bushnell, BSG]

address@hidden (Neal H. Walfield) writes:

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

How does the manager kill the process?  It isn't necessarily
running as root.  It had better work whether running as root or not.

I can think of two ways:

Way One: It sends a signal.  To make this work, use the same trick as
term. 

Way Two: It calls task_terminate.  To make this work, require the
locking task to provide its own task port when acquiring the lock.


However, way two is unacceptible, because users cannot be required to
trust file servers.

I would suggest neither Way One nor Way Two, and go for something
else:

If the manager sees that the lock is locked too long, it sends a
message to the task and forcibly releases the lock.  The process whose
lock has been broken can do what it likes (including, for example,
terminate).

Thomas