[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
establishing the callers PID
From: |
Marcus Brinkmann |
Subject: |
establishing the callers PID |
Date: |
Sun, 12 May 2002 02:16:44 +0200 |
User-agent: |
Mutt/1.3.28i |
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
- establishing the callers PID,
Marcus Brinkmann <=