Re: Further shmctl() SHM_LOCK strangeness

[Michael Kerrisk]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/