On Tue, 28 May 2002, Jos Backus wrote:
> Every time I press ^C after su'ing to root which has zsh as its shell, zsh
> exits. According to somebody on IRC this is related to the PAMification of su.
> Strangely enough this does not occur when I replace zsh with bash (both from
> Is anybody else seeing this? It's quite annoying.
Here is some old mail about this. Sorry I slowed down Alexander's fixes.
> From bde Fri Jun 15 11:47:15 2001
> Return-Path: <[EMAIL PROTECTED]>
> Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [22.214.171.124])
> by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA29875
> for <[EMAIL PROTECTED]>; Fri, 15 Jun 2001 00:18:28 +1000
> Received: (from ak03@localhost)
> by h132-197-97-45.gte.com (8.11.4/8.11.4) id f5EEIFC03934;
> Thu, 14 Jun 2001 10:18:15 -0400 (EDT)
> (envelope-from ak03)
> Message-ID: <[EMAIL PROTECTED]>
> X-Mailer: XFMail 1.4.7p2 on FreeBSD
> X-Priority: 3 (Normal)
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 8bit
> MIME-Version: 1.0
> In-Reply-To: <[EMAIL PROTECTED]>
> Date: Thu, 14 Jun 2001 10:18:15 -0400 (EDT)
> Organization: Verizon Laboratories Inc.
> Sender: [EMAIL PROTECTED]
> From: "Alexander N. Kabaev" <[EMAIL PROTECTED]>
> To: Bruce Evans <[EMAIL PROTECTED]>
> Subject: Re: su/zsh problems, proposed fix
> Cc: [EMAIL PROTECTED]
> Content-Length: 2770
> Lines: 54
> Status: RO
> > I've been worrying about the corresponding extra process for login, but
> > haven't found any serious problems yet (for SHELL=bash).
> > I think you mean tcsetpgrp, not just setpgrp (tscsetpgrp is what sets the
> > process group for keyboard signals). I'm surprised zsh doesn't call it.
> No I actually mean what I say. bash, ksh and our sh all call
> setpgrp(0, getpid()) at the startup time when they are running in interactive
> mode. zsh does not call setpgrp and that is the reason why it ends up in the
> same process group with its parent su process. This way when user pressed ^C,
> SIGINT signal is delivered to both, causing su to exit while leaving its child
> running. To operate properly, su should never exit _before_ the command it is
> running, and that is the reason why it should ignore termination signals while
> waiting for a child to complete.
> > Things are broken for SHELL=bash too. Signals work right after su to
> > a passwordless account, but su to a passwordful account leaves signals
> > apparently blocked for both su and the shell (^C has no effect). This
> > is the opposite of the problem with zsh. There is an extra su process
> > even for passwordless accounts although there is no extra login process
> > for login to passwordless accounts.
> This is a different problem than one I am reporting.
> > I don't think this is the correct fix. I would prefer the extra
> > processes to not exist. Failing that, maybe su could do the [tc]setpgrp()
> > calls for the child. It already does a tcsetpgrp() for the child if
> > the child gets stopped. The corresponding code for the parent in login
> > is much simpler. It is just "wait(NULL; PAM_END; exit(0);". This is
> > too simple to be correct. It doesn't return the child's exit status).
> > su.c also exits with a wrong value: it misuses the child's wait status.
> Yes, having two processed where there traditionally was just one is .. not
> convenient. As far as I understand, fork+exec is required solely to call
> PAM_EXIT do do a proper credentials cleanup, but unfortunately, I do not know
> how can it be done in any different way. Having su to call tcsetpgrp is useless,
> because it will effectively try to give control over the terminal to itself and
> presumably su's parent shell have already done that. Disabling signals so that
> su could never exit before its child because of keyboard related events seemed
> to me the most simple approach.
> > Bruce
> If we'll agree on the exact stategy for fixing these problems, I am willing to
> work on that and submit patches for further review ASAP. ^C bug rates very high
> on my annoyance scale :)
> E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]>
> Date: 14-Jun-2001
> Time: 09:58:10
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message