From owner-freebsd-current@FreeBSD.ORG Wed Aug 27 22:12:34 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 74E6C16A4BF for ; Wed, 27 Aug 2003 22:12:34 -0700 (PDT) Received: from mail2.sol.net (mail2.sol.net [206.55.64.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32C244008 for ; Wed, 27 Aug 2003 22:12:32 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: from aurora.sol.net (aurora.sol.net [206.55.65.130]) by mail2.sol.net (8.11.0/8.11.0/SNNS-1.04) with ESMTP id h7S5CTP63570; Thu, 28 Aug 2003 00:12:29 -0500 (CDT) Received: (from jgreco@localhost) by aurora.sol.net (8.12.8p1/8.12.9/Submit) id h7S5BDvF009880; Thu, 28 Aug 2003 00:11:13 -0500 (CDT) From: Joe Greco Message-Id: <200308280511.h7S5BDvF009880@aurora.sol.net> To: bde@zeta.org.au (Bruce Evans) Date: Thu, 28 Aug 2003 00:11:13 -0500 (CDT) In-Reply-To: <20030828140312.N2706@gamplex.bde.org> from "Bruce Evans" at Aug 28, 2003 02:33:20 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org 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: Thu, 28 Aug 2003 05:12:34 -0000 > On Wed, 27 Aug 2003, Joe Greco wrote: > > I've got a weirdness with kill(2). > > > > This code is out of Diablo, the news package, and has been working fine for > > some years. It apparently works fine on other OS's. > > > > In the Diablo model, the parent process may choose to tell its children to > > update status via a signal. The loop basically consists of going through > > and issuing a SIGALRM. > > > > This stopped working a while ago, don't know precisely when. I was in the > > process of debugging it today and ran into this. > > > > The specific OS below is 5.1-RELEASE but apparently this happens on 4.8 as > > well. > > Perhaps the children are setuid, the parent doesn't have appropriate > privelege and you are mistaken about this happening under 4.8 as well. Well, the parent process does the code I listed below early on in the initialization process - it pretty much does a little initialization, opens its socket (119), sheds privilege, and begins accepting conns. It then forks off processes for each connection. The program itself is not a suid executable, but rather relies on being launched by a root user. I'm not sure what "appropriate privilege" would be. If both the uid/euid of the parent match both the uid/euid of the child, I would expect to be able to kill the process... Client complains about the resulting problems also happening under 4.8 servers. Dunno. Could possibly be a separate issue. > In 5.x since at least rev.1.80 of kern_prot.c, only certain signals > not including SIGALRM can be sent from unprivileged processes to setuid > processes. > > This is very UN-unixlike although it is permitted as an-implementation- > defined restriction in at least POSIX.1-2001. It breaks^Wexposes bugs > in some old POSIX test programs and I don't have many security concerns > so I just disable it locally: > > %%% > Index: kern_prot.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/kern_prot.c,v > retrieving revision 1.175 > diff -u -2 -r1.175 kern_prot.c > --- kern_prot.c 13 Jul 2003 01:22:20 -0000 1.175 > +++ kern_prot.c 17 Aug 2003 04:26:00 -0000 > @@ -1395,4 +1387,5 @@ > return (error); > > +#if 0 > /* > * UNIX signal semantics depend on the status of the P_SUGID > @@ -1425,4 +1418,5 @@ > } > } > +#endif > > /* > %%% > > > Wot? Why can't I send it a signal? > > > > I've read kill(2) rather carefully and cannot find the reason. It says, > > > > For a process to have permission to send a signal to a process designated > > by pid, the real or effective user ID of the receiving process must match > > that of the sending process or the user must have appropriate privileges > > (such as given by a set-user-ID program or the user is the super-user). > > The implementation-defined restrictions are not documented, of course ;-). > > > Well, the sending and receiving processes both clearly have equal uid/euid. > > > > We're not running in a jail, so I don't expect any issues there. > > > > The parent process did actually start as root and then shed privilege with > > > > struct passwd *pw = getpwnam("news"); > > struct group *gr = getgrnam("news"); > > gid_t gid; > > > > if (pw == NULL) { > > perror("getpwnam('news')"); > > exit(1); > > } > > if (gr == NULL) { > > perror("getgrnam('news')"); > > exit(1); > > } > > gid = gr->gr_gid; > > setgroups(1, &gid); > > setgid(gr->gr_gid); > > setuid(pw->pw_uid); > > > > so that looks all well and fine... so why can't it kill its own children, > > and why can't I kill one of its children from a shell with equivalent > > uid/euid? > > Changing the ids is one way to make the process setuid (setuid-on-exec is > another but that doesn't seem to be the problem here). The relevant setuid > bit (P_SUGID) is normally cleared on exec, but perhaps it isn't here, > either because the children don't exec or the effective ids don't match > the real ids at the time of the exec. The children aren't spawned via exec, but clearly they have equal uid/euid's. So what you're saying, I guess, is it's not supposed to work. I guess I'm a bit confused by the logic of this. I've seen numerous forking daemons over the years that do this sort of thing (not to mention I've written a number). I've always viewed shedding root privs as being a good thing... Was it really intended to break things in this manner? > > I know there's been some paranoia about signal delivery and all that, but > > my searching hasn't turned up anything that would explain this. Certainly > > the manual page ought to be updated if this is a new expected behaviour or > > something... at least some clue as to why it might fail would be helpful. > > Certainly. It is incomplete even not counting complications for jails > or other implementation-defined restrictions related to "appropriate > privilege". Sigh. Thanks for the note, ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.