establishing the callers PID

[Marcus Brinkmann]

Hi,

for POSIX locking and shared memory, the filesystem needs to establish the
callers identity (its PID).  Well, actually, in some cases, a system wide
unique ID would be enough.  For example in the case of file locks, it would
be enough to have a send right to a receive right in the caller's task. 
Unfortunately, GETLK requires to fill in the PID in the task structure. 
There is no freedom :(

I think it is absolutely mandatory that we establish the PID in a
trustworthy way rather than let the user provide some unique ID on its own.
I think there is already a place in the Hurd where we should do that but
don't (wasn't that term's term_open_ctty?), and there are all sort of simple
attacks possible if we can't trust the PID (eg a monitor server might check
for stale advisory locks and kill processes that don't release them timely. 
In the untrusted model, a user could make this monitor process kill
arbitrary processes on the system).

So we need a handshake protocol like we have in auth, but in the proc
server.  The proc server could then establish the pid of a user to the
server.  However, I am not sure this 1:1 correspondence is a good fit for
what we need, there are slight variations possible, too.

For one, let's take a look at what we need for advisory record locking:
Locks are not inherited across fork().  Locks are released at task
termination.  This sounds like we could make good use of either a receive
right in the task for which a send right is given to the server, or
alternatively support by the proc server.

This is still very vague, but one way I think about this problem is that
if the client gives the server a port and a trusted pid (through proc),
then some of the tougher requirements of POSIX for record locking would
be easy to implement (everything related to process termination, fork/exec
behaviour, and pid).  The other way I think about it is that the proc server
does not pass through a port from the client, but just gives the server a
process info port on behalf of the client, on which the server can make
various RPCs to get the pid, and to request a task died notification.
Depending on in which way we want to extend this in the future, either
way might be better or worse.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de