From owner-freebsd-current@FreeBSD.ORG Fri Dec 22 21:08:12 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 0E67716A403; Fri, 22 Dec 2006 21:08:12 +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 CC0A013C459; Fri, 22 Dec 2006 21:08:11 +0000 (UTC) (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 ACB964711F; Fri, 22 Dec 2006 15:51:05 -0500 (EST) Date: Fri, 22 Dec 2006 20:51:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061221233855.GA95581@nagual.pp.ru> Message-ID: <20061222204908.C65423@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> <20061217153914.GA30048@nagual.pp.ru> <20061221233855.GA95581@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: Fri, 22 Dec 2006 21:08:12 -0000 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