From owner-freebsd-hackers  Sat Sep  2 14:40:09 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA07290
          for hackers-outgoing; Sat, 2 Sep 1995 14:40:09 -0700
Received: from vax.cs.pitt.edu (vax.cs.pitt.edu [136.142.79.5])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA07278
          for <hackers@freebsd.org>; Sat, 2 Sep 1995 14:40:05 -0700
Received: from w2xo.pgh.pa.us by vax.cs.pitt.edu (8.6.10/1.14)
	for <hackers@freebsd.org>; id RAA05975; Sat, 2 Sep 1995 17:40:09 -0400
Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.11/8.6.9) id RAA00393; Sat, 2 Sep 1995 17:35:17 -0400
Date: Sat, 2 Sep 1995 17:35:14 -0400 (EDT)
From: Jim Durham <durham@w2xo.pgh.pa.us>
To: hackers@freebsd.org
Subject: A little strangness with 2.0.5
Message-ID: <Pine.BSF.3.91.950902171150.346A@w2xo.pgh.pa.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@freebsd.org
Precedence: bulk

I had earlier posted to the newsgroup regarding tty level buffer overflows with
software ported to 2.0.5 from 1.1.5.1 that occured only occasionally with
1.1.5.1 but continually with 2.0.5.

It turns out that the overflows are not the problem, but a symptom.
Further investigation showed that the process was hanging with the
serial ports open()ed. It was hanging on a wait() call, according to
gdb. It turns out that it was a wait() call after the kill of a child
process.

Checking permissions found this
parent:	rwsr-xr-x  net  wheel
child:  rwsr-xr-x  net  staff

This should have worked OK, but the parent could not kill the child which
had been exec()'d by it. the kill(pid, -9) call was returning the "permission
denied" error.

After a lot of playing around, I decided that, although it shouldn't make
any difference, I'd change the group of the parent to "staff". I also
changed the permissions to 6755 (rwsr-sr-x) just in desperation.

Now it works!

I *think* what was happening was that in 1.1.5.1, the wait was occasionally
causing the process to wait too long and I'd get an occasional overflow.
In 2.0.5, it hangs completely when the kill() fails. This same code
worked flawlessly with Ultrix 3.1 on my old Microvax II .

I thought this behavior was strange enough that it might be worth
asking if anyone could shed any light on why this was happening.
Perhaps it has an explanation in something I was doing, but it *might*
indicate something screwy with how permissions are handled with 2.0.5.

My problem is "solved" at the moment, but something is not "cricket"
and may bite someone else. Why should the group ID have any effect
on kill permissions?

Here's the code that caused the problem:

	case DISCONNECTED:  fwdbbsstate=NOCON;
			    if(kill(fwdstruct.pid,9) < 0)
				    perror("fwdstate:");
			    wait(NULLCHAR);

"fwdstruct.pid" DID contain the correct PID, BTW.

-Jim Durham