From owner-freebsd-arch@FreeBSD.ORG Wed Jun 24 15:32:36 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DB810656D7; Wed, 24 Jun 2009 15:32:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A0B2F8FC15; Wed, 24 Jun 2009 15:32:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 56BE31A3C3A; Wed, 24 Jun 2009 08:32:36 -0700 (PDT) Date: Wed, 24 Jun 2009 08:32:36 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20090624153236.GN84786@elvis.mu.org> References: <200906231341.43104.jhb@freebsd.org> <200906231706.33465.jhb@freebsd.org> <20090623230501.GH84786@elvis.mu.org> <200906240833.04028.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906240833.04028.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 15:32:37 -0000 * John Baldwin [090624 07:23] wrote: > On Tuesday 23 June 2009 7:05:01 pm Alfred Perlstein wrote: > > * John Baldwin [090623 14:07] wrote: > > > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm??rgrav wrote: > > > > John Baldwin writes: > > > > > There have been a several issues with the existing ABI of the SYSV IPC > > > > > structures over the past several years and it has been on the todo list for > > > > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down > > > > > and worked on it this week. > > > > > > > > Have you given any thought to virtualization, i.e. separate namespaces > > > > for each jail? Will your patch make this any easier or harder to > > > > implement? > > > > > > It likely has zero effect on that. The global variables one would need to > > > virtualize are unchanged by this. > > > > John, would it make sense to check for overflow in ipcperm_new2old and return > > some error so that callers get back some nasty error so that they don't make > > a mistake about permissions when an overflow happens? > > > > A crash/error sounds better than silent truncating of credential information, > > but I could be wrong. > > Hmm, well, the truncation is what we have been doing all along for any users > who used UIDs > USHRT_MAX, so adding an error now would change the behavior > for existing binaries. Also, the truncation does not affect the actual > permission checks (those are all done in the kernel), merely the reporting of > the associated IDs to userland. OK, thank you for explaining. -- - Alfred Perlstein