Date: Thu, 14 Jun 2001 10:18:15 -0400 (EDT) From: "Alexander N. Kabaev" <ak03@gte.com> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-audit@FreeBSD.ORG Subject: Re: su/zsh problems, proposed fix Message-ID: <XFMail.20010614101815.ak03@gte.com> In-Reply-To: <Pine.BSF.4.21.0106141935470.74658-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 -------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20010614101815.ak03>