From owner-freebsd-current@FreeBSD.ORG Sat Dec 16 13:25:00 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78ABD16A403; Sat, 16 Dec 2006 13:25:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AE543CB3; Sat, 16 Dec 2006 13:25:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C5F3446E1F; Sat, 16 Dec 2006 08:24:59 -0500 (EST) Date: Sat, 16 Dec 2006 13:24:59 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061216131135.GA1393@nagual.pp.ru> Message-ID: <20061216131715.C72986@fledge.watson.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 13:25:00 -0000 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