From owner-freebsd-current@FreeBSD.ORG Sat Aug 30 09:06:28 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F30B16A4BF; Sat, 30 Aug 2003 09:06:28 -0700 (PDT) Received: from hexagon2.stack.nl (hexagon2.stack.nl [131.155.140.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1569343FD7; Sat, 30 Aug 2003 09:06:23 -0700 (PDT) (envelope-from jilles@stack.nl) Received: from toad.stack.nl (zen.stack.nl [IPv6:2001:610:1108:5010::130]) by hexagon2.stack.nl (Postfix) with ESMTP id DCC655C016; Sat, 30 Aug 2003 18:06:02 +0200 (CEST) Received: by toad.stack.nl (Postfix, from userid 1677) id 67BB5D1; Sat, 30 Aug 2003 18:06:20 +0200 (CEST) Date: Sat, 30 Aug 2003 18:06:19 +0200 From: Jilles Tjoelker To: Robert Watson Message-ID: <20030830160618.GA52499@stack.nl> References: <200308281432.h7SEWsma031504@aurora.sol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-current@freebsd.org cc: Joe Greco Subject: Re: Someone help me understand this...? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Aug 2003 16:06:28 -0000 On Thu, Aug 28, 2003 at 11:34:09AM -0400, Robert Watson wrote: > > > Clearly, unbreaking applications like Diablo by default is desirable. At > > > least OpenBSD has similar protections to these turned on by default, and > > > possibly other systems as well. As 5.x sees more broad use, we may well > > > bump into other cases where applications have similar behavior: they rely > > > on no special protections once they've given up privilege. I wonder if > > > Diablo can run unmodified on OpenBSD; it could be they don't include > > > SIGALRM on the list of "protect against" signals, or it could be that they > > > modify Diablo for their environment to use an alternative signaling > > > mechanism. Another alternative to this patch would simply be to add > > > SIGARLM to the list of acceptable signals to deliver in the > > > privilege-change case. OpenBSD does not consider a process 'tainted' if it changes credentials while running. From the issetugid(2) manpage: The status of issetugid() is only affected by execve(). > In most cases, fail-stop is a reasonable behavior for unexpected security > behavior from the system, but ignore is likely to shoot you later. :-) I > tend to wrap even kill() calls as uid 0 in an assertion check, just to be > on the safe side. If nothing else, it helps detect the case where the > other process has died, and you're using a stale pid. It's particular > useful if the other process has died, the pid has been reused, and it's > now owned by another user, which is a real-world case where kill() as a > non-0 uid can fail even when you're sure it can't :-). This can be avoided by careful programming: do not use SA_NOCLDWAIT and don't pass pids to kill() when they have been returned by wait() or similar functions. If the process has terminated in between, it's a zombie. In that case, FreeBSD probably returns ESRCH but SUSv3 mandates returning success (but performing no action). Jilles Tjoelker