From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 19:32:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBEBE16A422; Mon, 3 Apr 2006 19:32:21 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38EDA43D48; Mon, 3 Apr 2006 19:32:21 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 34E198244BB; Mon, 3 Apr 2006 16:32:18 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66550-07; Mon, 3 Apr 2006 16:32:20 -0300 (ADT) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id A7674823A52; Mon, 3 Apr 2006 16:32:17 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id AF9DE3C090; Mon, 3 Apr 2006 16:32:20 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id A9C9438808; Mon, 3 Apr 2006 16:32:20 -0300 (ADT) Date: Mon, 3 Apr 2006 16:32:20 -0300 (ADT) From: "Marc G. Fournier" To: Daniel Eischen In-Reply-To: Message-ID: <20060403163039.O947@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Cc: Peter Jeremy , freebsd-stable@freebsd.org Subject: Re: [HACKERS] semaphore usage "port based"? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 19:32:21 -0000 On Mon, 3 Apr 2006, Daniel Eischen wrote: > On Tue, 4 Apr 2006, Peter Jeremy wrote: > >> On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote: >>> I don't really see what the problem is. ESRCH seems perfectly >>> reasonable for trying to kill (even sig 0) a process from a >>> different jail. If you're in a jail, then you shouldn't have >>> knowledge of processes from other jails. >> >> I agree in general. The problem here is that SysV IPC isn't >> jail-aware - there's a single SysV IPC address space across the >> physical system. This confuses (eg) postgres because it can >> see the SHM for a postgres instance in another jail but kill(2) >> claims that the process associated with that SHM doesn't exist. >> >> There appear to be two solutions: >> 1) Add a sysctl to change cr_cansignal() and/or prison_check() to >> make processes visible between jails. >> 2) Change SysV IPC to be jail-aware. >> >> The former is trivial - but has a number of security implications. >> The latter is much harder, there is apparently a RELENG_4 patch in >> kern/48471 but it's not clear how much work would be necessary to >> being it up to scratch. > > Or: > > 3) Run postgres in such a way that it doesn't look for > remnant IPC information from other instances (use a > per-jail-specific port #?). > > Postgres has no business cleaning up after different jailed > instances of itself, which it wouldn't do if IPC's were > per-jail. So since IPC's don't currently work that way, > account for it by the way you run postgres. This falls under "well,we broke kill() so that it now reports a PID is not in use even though it is, so its has to be the application that fixes it" ... and you *still* haven't shown *why* kill() reporting a PID is in use, even if its not in the current jail, is such a security threat ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664