sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in
-current)
Robert Watson
rwatson at FreeBSD.org
Sat Dec 16 05:01:02 PST 2006
On Sat, 16 Dec 2006, Andrey Chernov wrote:
> On Sat, Dec 16, 2006 at 12:11:05PM +0000, Robert Watson wrote:
>>> * Always permit the creator/owner to update the object
>>> * protections regardless of whether the object mode
>>> * permits it.
>>> */
>>> if (mode & IPC_M)
>>> return (0);
>>>
>>> I.e. old code not even check for IPC_W or IPC_R in case of IPC_M presense.
>>
>> Is this conclusion a supposition or the result of testing? Could you test
>> and see if this is true?
>
> It comes just from code reading. First check for owner and next check for
> IPC_M bit _only_ (no other bits!) then return (0) i.e. success.
Only if IPC_M is being requested. Is IPC_M being requested in the case where
you are seeing an error? I can read code too, so what I'm asking is how the
system is behaving.
>>> Moreover, old code allows _anything_ for suser:
>
>> The new code should also allow anything, as long as the bits passed into
>> ipcperm() as requested modes are valid. There's certainly a bug here
>
> I mean anything for suser ignoring completely any modes passed. I.e. no
> EACCES should happen for suser in _any_ mode combination.
No, ipcperm() will return an access control error if an invalid access mode is
requested. We grant valid rights, not all rights, to the super user. I'm
fairly certain there's a bug in my ipcperm(), possibly in the manipulation of
read/write bits, etc. However, the question is why the bug is causing a
problem at all. The second call to shmget() in the sample code provided by
the original submitter shouldn't actually need to call ipcperm(), since we
don't authorize access to the name space based on IPC permissions, only access
to the IPC objects. This suggests that shmget() is improperly calling
ipcperm(), and that the call needs to be removed.
As I said, this is something that I hope to revisit in the next few days.
However, it would be helpful if you could tell me the arguments and call path
to the ipcperm() function instance that's generating the improper failure.
It could be that both a bug in ipcperm() and a big in shmget() need to be
fixed. The reason I've delayed fixing it so far is that I think the bug in
shmget() has to do with poorly defined semantics for shmget(), and I want to
make sure I'm fixing the system to use the correct semantics. Unfortunately,
that has proven tricky as the specifications re the source of the poorly
defined semantics.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list