sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in
-current)
Robert Watson
rwatson at FreeBSD.org
Fri Dec 22 13:08:12 PST 2006
On Fri, 22 Dec 2006, Andrey Chernov wrote:
> On Sun, Dec 17, 2006 at 06:39:14PM +0300, Andrey Chernov wrote:
>> On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote:
>>> 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()
>>
>> This is kernel debug running test from t-shm.c which fails (from root). Is
>> it what you need?
>>
>> acc_mode 0x1b0
>> owner
>> obj_mode 0x9b0
>> dac_granted 0x1180
>> priv_granted 0x0
>> EACCES
>
> Any reaction?
Yes -- it looks like the call to ipcperm() in shmget_existing() is a bug; the
flags argument should be ignored for access control purposes when shmget() is
accessing an existing object rather than creating a new one. I've done a bit
of reading of Solaris and Linux code and need to write some tests to confirm
my understanding and make sure we're behaving consistently. I hope to get a
chance to do this next week some time after I return from Oxford. If you
want, you can try removing the ipcperm() call from shmget_existing() and
restore the sysv_ipc.c change and see how that works for you?
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list