From owner-freebsd-current Mon Aug 12 4: 3:37 2002 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 EC71E37B400; Mon, 12 Aug 2002 04:03:34 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A8843E4A; Mon, 12 Aug 2002 04:03:34 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0085.cvx21-bradley.dialup.earthlink.net ([209.179.192.85] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eCyz-0000TN-00; Mon, 12 Aug 2002 04:03:34 -0700 Message-ID: <3D579529.C7DA2171@mindspring.com> Date: Mon, 12 Aug 2002 03:59:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Robbins Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_sig.c (fwd) References: <20020811132854.99343.qmail@web20907.mail.yahoo.com> <3D571562.B7CDC954@elischer.org> <20020812201725.A20609@dilbert.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Tim Robbins wrote: > 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. Obviously it's different, if it behaves differently. The issue is whether or not a kernel change in signal handling means that the su code that has been in FreeBSD for many years is now "magically" no longer the right way to do things. The effects not only the su code itself, but any code out there that anyone has written, which is either derived from the old su code, or modelled on the way the old code has done things. It's all well and good to work around a kernel bug by changing user space code, but working around it by changing the user space code *hardly* fixes the underlying bug, which will just sit there waiting to bite the next poor unsuspecting slob on the arse. > 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(). It should not be required that you do this. It's pretty obvious what is happening, if blocking the signals works around the problem: signal delivery requires a stall barrier until after the fork inheritance has been cleaned up. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message