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

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Sat, 16 Dec 2006 13:24:59 +0000 (GMT)
On Sat, 16 Dec 2006, Andrey Chernov wrote:

> On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote:
>> 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.
>
> I'll track exact case a bit later. For now I just speak about differences 
> between new code and old code I found. New code check all bits match while 
> old code check IPC_M bit match only at this place.

As I said, I can read code too.  The changes in access control logic are 
intentional and conservative.  There is at least one bug, and possibly two 
bugs, in play here.  The basic situation is that the user application is 
relying on undefined behavior of the API.  Previously, we implemented that 
undefined behavior by accident: we appear to be improperly checking for 
access, but due to the flexibility of the checks, we grant them.  We need to 
now implement the undefined behavior on purpose, since the new access control 
implementation is structured.  A bug in the new ipcperm() may well be 
triggering the appearance of the error, but it appears also to be a product of 
incorrectly structured code in the existing shared memory implementation. The 
long-term goal is to have a correct implementation of the new code, not simply 
revert to the old code.

>> is requested.  We grant valid rights, not all rights, to the super user.
>
> This is clearly wrong. Think about files. Even file is read-only, root _can_ 
> write into it while normal user in the same situation can't.

No, it is not wrong.  We grant only valid rights, we don't grant invalid 
rights.  One of the possible bugs here is that an invalid request for rights 
is being made, which would result in an access failure.  The existing code 
might not detect that, the new code will.

> root> touch aaa root> chmod 444 aaa root> cat > aaa OK

These are all valid rights, so they are accepted.

>> 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()
>
> I'll try to make ktrace output, a bit later.

That's not what I asked for.

Robert N M Watson
Computer Laboratory
University of Cambridge
Received on Sat Dec 16 2006 - 12:25:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC