Date: Sat, 16 Dec 2006 13:24:59 +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: <20061216131715.C72986@fledge.watson.org> In-Reply-To: <20061216131135.GA1393@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> <20061216125419.J72986@fledge.watson.org> <20061216131135.GA1393@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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061216131715.C72986>