Date: Thu, 14 Jun 2001 21:17:31 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Alexander N. Kabaev" <ak03@gte.com> Cc: freebsd-audit@FreeBSD.ORG Subject: Re: su/zsh problems, proposed fix Message-ID: <Pine.BSF.4.21.0106141935470.74658-100000@besplex.bde.org> In-Reply-To: <20010613143921.A65820@kanpc.gte.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Jun 2001, Alexander N. Kabaev wrote: > There is a problem with su in -CURRENT when used by the users who have zsh set > as their login shell. zsh never calls setpgrp on startup itself but rather > relies on its parent to do that if so desired. After PAM support has been added > to su in -CURRENT, causing su to change its previous behavior of doing exec to > run the command to fork+exec+waitpid sequence, running su -m from the command > line results in su and zsh processes both running in the same process group. I've been worrying about the corresponding extra process for login, but haven't found any serious problems yet (for SHELL=bash). > Now > if user presses ^C on the keyboard, SIGINT signal is dispatched to both su and > zsh processes. zsh runs in interactive mode, so it ignores the signal and > continues to run, while su itself dies. The parent shell process then detects > su's death and mistakenly tries to regain control over the terminal, conflicting > with the still alive shell which has been previously spawned by su. Failing > that, the parent shell dies abnormally with TTY input/output error message and > takes your xterm/login session/screen window/etc along. 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. 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. > Attached patch attempts to resolve this issue by changing su to ignore SIGINT, > SIGQUIT and SIGTSTP signals while waiting for the child to complete. I have been > running -CURRENT for at least two weeks now with the patch applied and I did not > have any problems with it so far. I submitted this patch to Mark Murray earlier > today and he did not have problem with it and he suggested that the patch should > be posted on audit@freebsd.org for further review. 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. Bruce 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?Pine.BSF.4.21.0106141935470.74658-100000>