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 CambridgeReceived on Fri Dec 22 2006 - 20:08:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC