Messages in this thread | | | Date | Thu, 25 Nov 2004 17:30:14 +0100 (MET) | From | "Michael Kerrisk" <> | Subject | Re: Further shmctl() SHM_LOCK strangeness |
| |
Rik,
> On Thu, 25 Nov 2004, Michael Kerrisk wrote: > > > I don't think this is sufficient -- there must > > be protection against arbitrary SHM_LOCKs. > > Why? We already have ulimits do that...
My gut feeling is that processes should not be able to arbitrarily lock shared memory segments created by other users in memory. I mean: why should I be able to someone else's segment into shared memory when I can't even access the contents of that shared memory. (Such semantics are simply inconsistent with the System V IPC model.)
Also (more below), I don't see any other sensible semantics for these operations, other than the ones I've proposed.
> > How about the following: > > > > For *both* SHM_LOCK and SHM_UNLOCK, the process should either > > be the owner or the creator of the object or have the > > CAP_IPC_LOCK capability. > > It makes a lot of sense, but I don't know whether or not > it'd break any applications...
There is no reason why it should. In 2.6.8, the only processes that could lock shared memory segments were those with CAP_IPC_LOCK. Unprivileged processes did not get a look in.
2.6.9 changed things, but it is very unlikely that any applications depend on this (yet). Most userland developers are probably not even aware of the changed semantics in 2.6.9. The time to repair these semantics is *now*, before someone does depend on them. (In any case changes are required, since at a minimum, SHM_UNLOCK must be repaired.)
You earlier suggested the idea that SHM_UNLOCK might check to see if the process's user ID matched that of the process that did the SHM_LOCK. This doesn't work. Suppose someone else locks *my* segment (even though they don't have permission to access its contents or perform other "ctl" operations on it like IPC_RMID). Under your idea, I would not be able to do a SHM_UNLOCK to remove that lock.
Cheers,
Michael
-- Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD ++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |