Date: Sat, 30 Aug 2003 18:06:19 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Robert Watson <rwatson@freebsd.org> Cc: Joe Greco <jgreco@ns.sol.net> Subject: Re: Someone help me understand this...? Message-ID: <20030830160618.GA52499@stack.nl> In-Reply-To: <Pine.NEB.3.96L.1030828111808.35478C-100000@fledge.watson.org> References: <200308281432.h7SEWsma031504@aurora.sol.net> <Pine.NEB.3.96L.1030828111808.35478C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030830160618.GA52499>