Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current)

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