|
From: | Niklas Höglund |
Subject: | Re: PID of client requirements |
Date: | Tue, 05 Nov 2002 17:48:40 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |