Date: Mon, 12 Aug 2002 20:17:25 +1000 From: Tim Robbins <tjr@FreeBSD.ORG> To: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_sig.c (fwd) Message-ID: <20020812201725.A20609@dilbert.robbins.dropbear.id.au> In-Reply-To: <3D571562.B7CDC954@elischer.org>; from julian@elischer.org on Sun, Aug 11, 2002 at 06:54:42PM -0700 References: <20020811132854.99343.qmail@web20907.mail.yahoo.com> <3D571562.B7CDC954@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 11, 2002 at 06:54:42PM -0700, Julian Elischer wrote:
> I am forwarding this to -current as I think it needs more neurons on it..
> I am presently unable to spend any due to work commitments, and due to a =
sort-of=20
> personal confusion about tis stuff anyhow..
> =18
>=20
> David Xu wrote:
> >=20
> > does anyone believe that su behaviours correctly?
> > we are talking that kernel has bug to handle job control
> > but I found that the issue may not related to signal handling
> > problem, but related to su or csh's job control.
> > I see this piece of code in su.c:
> >=20
> > switch (child_pid) {
> > default:
> > while ((ret_pid =3D waitpid(child_pid, &statusp, WUNTRA=
CED)) !=3D eca-1) {
> > if (WIFSTOPPED(statusp)) {
> > child_pgrp =3D tcgetpgrp(1);
> > kill(getpid(), SIGSTOP);
> > tcsetpgrp(1, child_pgrp);
> > kill(child_pid, SIGCONT);
> > statusp =3D 1;
> > continue;
> > }
> > break;
> > }
> >=20
> > I have traced down su. In my test, the su process forked a
> > child process, child process pid is 873 while parent pid is 872.
> > these code are in question, I found that tcgetpgrp(1) really
> > returns parent su pid, it is 872, parent su process
> > then suspends itself until login shell unsuspends it,
> > when it resumes, I have inserted another tcgetpgrp(1) after it resumes,
> > and found that it was 873, it was child su process pid! not 872,
> > because parent su was not in foreground group, when it called tcsetpgrp=
(1, 872),
> > it got a SIGTTOU and suspended there, the SIGCONT was not sent out.
> > so the code's behaviour is not what the author's want, and all job
> > control gets weird. I suguest this job control assumption should be rem=
oved,
> > strange thing is why su calls fork()? why doesn't call directly execvl(=
)?
> > I don't see su calls fork() in OpenBSD.
I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works
well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$
that I complained about earlier.
This means that either our su is broken, or the different way Redhat
has implemented it is managing to avoid a kernel bug of ours.
I've extracted Redhat's patch from the RPM to make it easier to get:
http://people.freebsd.org/~tjr/sh-utils-1.16-pam.patch
The patch applies cleanly to sh-utils-1.16 (find it on a GNU mirror),
and su gets built - the build process dies at `test'.
The key differences with our implementation seem to be that they block
all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the
fork on the parent side (race?), and they don't mess around with
tc[gs]etpgrp().=20
Tim
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020812201725.A20609>