Date: Sat, 16 Dec 2006 13:00:56 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andrey Chernov <ache@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current) Message-ID: <20061216125419.J72986@fledge.watson.org> In-Reply-To: <20061216125136.GA1094@nagual.pp.ru> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061216125419.J72986>