Date: Wed, 29 May 2002 10:55:54 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jos Backus <jos@catnook.com> Cc: freebsd-current@FreeBSD.ORG, <des@FreeBSD.ORG> Subject: Re: zsh exits upon ^C after su'ing to root with zsh as its shell Message-ID: <20020529105048.W23368-100000@gamplex.bde.org> In-Reply-To: <20020528224503.GE11876@lizzy.catnook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > ports). > > 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: <ak03@gte.com> > Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) > by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA29875 > for <bde@zeta.org.au>; 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: <XFMail.20010614101815.ak03@gte.com> > 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: <Pine.BSF.4.21.0106141935470.74658-100000@besplex.bde.org> > Date: Thu, 14 Jun 2001 10:18:15 -0400 (EDT) > Organization: Verizon Laboratories Inc. > Sender: ak03@gte.com > From: "Alexander N. Kabaev" <ak03@gte.com> > To: Bruce Evans <bde@zeta.org.au> > Subject: Re: su/zsh problems, proposed fix > Cc: freebsd-audit@FreeBSD.ORG > Content-Length: 2770 > Lines: 54 > Status: RO > X-Status: > X-Keywords: > > > > > I've been worrying about the corresponding extra process for login, but > > haven't found any serious problems yet (for SHELL=bash). > <SKIP> > > 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 <ak03@gte.com> > Date: 14-Jun-2001 > Time: 09:58:10 > -------------------------------------------- Bruce 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?20020529105048.W23368-100000>