[Top][All Lists]

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

Re: PID of client requirements

From: Thomas Bushnell, BSG
Subject: Re: PID of client requirements
Date: 04 Nov 2002 20:58:47 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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

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

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,


reply via email to

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