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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
