From owner-freebsd-stable@FreeBSD.ORG Mon Apr 3 15:49:53 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 CBC6116A400 for ; Mon, 3 Apr 2006 15:49:53 +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 2E6E243D48 for ; Mon, 3 Apr 2006 15:49:53 +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 7C3AE46CEF; Mon, 3 Apr 2006 11:49:52 -0400 (EDT) Date: Mon, 3 Apr 2006 16:49:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Lane In-Reply-To: <27417.1144033691@sss.pgh.pa.us> Message-ID: <20060403164139.D36756@fledge.watson.org> References: <20060402163504.T947@ganymede.hub.org> <25422.1144016604@sss.pgh.pa.us> <25526.1144017388@sss.pgh.pa.us> <20060402213921.V947@ganymede.hub.org> <26524.1144026385@sss.pgh.pa.us> <20060402222843.X947@ganymede.hub.org> <26796.1144028094@sss.pgh.pa.us> <20060402225204.U947@ganymede.hub.org> <26985.1144029657@sss.pgh.pa.us> <20060402231232.C947@ganymede.hub.org> <27148.1144030940@sss.pgh.pa.us> <20060402232832.M947@ganymede.hub.org> <20060402234459.Y947@ganymede.hub.org> <27417.1144033691@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Marc G. Fournier" , pgsql-hackers@postgresql.org, freebsd-stable@freebsd.org, Kris Kennaway 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 15:49:54 -0000 On Sun, 2 Apr 2006, Tom Lane wrote: > Oops. Here is the problem: kill() is lying by claiming there is no such > process as 83699. It looks to me like there in fact is such a process, but > it's in a different jail. > > I venture that FBSD 6 has decided to return ESRCH (no such process) where > FBSD 4 returned some other error that acknowledged that the process did > exist (EPERM would be a reasonable guess). > > If this is the story, then FBSD have broken their system and must revert > their change. They do not have kernel behavior that totally hides the > existence of the other process, and therefore having some calls that pretend > it's not there is simply inconsistent. FreeBSD's mandatory access control models, such as multi-level security, biba integrity, and type enforcement, will generally provide consistent protection under the circumstances you describe: specifically, that information flow invariants across IPC types, including System V IPC and inter-process signalling, will allow flow only in keeping with the policy. However, I guess I would counter with the following concern: the PID returned by semctl() has the following definition: GETPID Return the pid of the last process to perform an operation on semaphore number semnum. However, pid's in general uniquely identify a process only at the time they are recorded. So any pid returned here is necessarily stale -- even if there is another process with the pid returned by GETPID, it may actually be a different process that has ended up with the same pid. The longer the gap since the last semaphore operation, the more likely (presumably) it is that the pid has been recycled. And on modern systems with thousands of processes and high process turn-over (i.e., systems with CGI and other sorts of scripting),pid reuse can happen quickly. Is your use of the pid here consistent with fact that pid's are reused quickly after process exit? Use of pid's in UNIX is often unreliable, and must be combined with other synchronizing, such as file locking on a pidfile, to ensure that the pid read is valid. Even then, you can't implement atomic check-pid-and-signal using current UNIX APIs, which would require a notion of a process handle (or, in the parlance of Mach, a task port). Another thought along these lines -- especially with the proliferation of fine-grained access control systems, such as Type Enforcement in SELinux, I would be cautious about assuming that two processes being able to manipulate the same sempahore implies the ability to exchange signals using the signal facility. Robert N M Watson