Re: PID of client requirements

[Niklas Höglund]

On gmane.os.hurd.devel.readers Marcus Brinkmann wrote:
> Now imagine some unprivileged rogue process being able to set a
> lock on the file.  In the POSIX world, this would be rather safe: Although
> it would now have a lock (and thus might be able to make other privileged
> processes stall if they relying on the lock), the manager process might at
> some time notice it and kill this rogue process.  Net effect is that a bug
> in the subsystem (makes the lock file readable for unprivileged users) is
> only a small bug local to this subsystem (an attacker can only make this
> subsystem hang by grabbing the lock for a while).
>
> In the Hurd world, the rogue process could insert the PID of the root
> filesystem, leading to a desaster.  So a small bug in the POSIX world would
> be a grave bug in the Hurd implementation.
>
> Now, the above locking example is not the ideal example, in that it relies
> on a bug in the first place to illustrate the problem.  Lock files should
> not be readable or writable to untrusted users.

I can imagine cases where you'd want, for example, many people to be 
able to read from a database (here implemented as a single file).  In 
order for them to be able to read without getting corrupted data if 
modifications happen simultaneously, they're allowed to lock the file 
with a shared lock.

If modifications don't happen very often I'd not consider it a bug if 
the privileged user that has write access to the file has to wait for 
say 30 seconds (before killing any hung readers) to get a write lock.

This file could for example be a schedule database in a school.  You'd 
allow all students to read it, but only teachers get write access.


One solution off the top of my head is to do an extra check when locking 
the file.

A -> B:  lock this file with my pid 1234
B -> PID 1234:  Did you request for me to lock this file?
PID 1234 -> B:  Yes.               (The PID is correct.)
PID 1234 -> B:  No, or no answer.  (The PID isn't correct.)

--
                                                Niklas

P.S.
I don't know much about POSIX so this may all be very wrong.