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


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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages