Bug#317747: su -m / suspend / fg broken with zsh
Package: login Version: 1:4.0.3-36 this bug has been introduced since 1:4.0.3-35 ... perhaps related to the fix for #314727. with zsh as your shell, this sequence is busted: dotlark:~% su -m Password: [EMAIL PROTECTED]:~# suspend zsh: suspended su -m dotlark:~% fg [1] + continued su -m [EMAIL PROTECTED]:~# zsh: suspended (signal) su -m dotlark:~% wwat zsh: command not found: h at the end there i tried to type what just to show that the input was going to both shells simultaneously. the problem doesn't seem to happen if i drop the -m, or if i use bash or tcsh as the shell instead... the latter might point to this being a zsh problem, but it is a new thing since -35 and zsh hasn't changed, so i figured i'd start here. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: su -m / suspend / fg broken with zsh
i'm pretty sure this is because bash and tcsh create their own process group at startup, and zsh doesn't... so zsh shares the same process group as the su process. suppose we have this pstree fragment: zsh(4782,dean)---su(4788,root)---zsh(4789) both pids 4788 and 4789 have pgrp 4788. when zsh suspends itself it sends SIGTSTP to -4788. this TSTP hits both zsh(4789) and su(4788) -- which causes zsh(4782) to finish its waitpid (it was waiting on su(4788)). note that su(4788) has been stopped here *before* it issues raise(SIGSTOP). then a while later when you type fg in zsh(4782), it sends a CONT to -4788, which wakes both 4788 and 4789... now unfortunately the su continues on in the new 356_su-stop_cont-proxy patch ... it finally gets to do its raise(SIGSTOP)... and presto, that wakes up zsh(4782) again... and now both zsh processes are awake and fighting for the tty. i think su should be creating a new process group for its child... unfortunately when i throw in a setpgrp() in the child it's still not sufficient -- after a couple suspend/fg cycles i get into the same problem. hmm. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: su -m / suspend / fg broken with zsh
ok this is gross... but this seems to fix the problems. at first i tried just adding the setpgrp... but with that the su'd zsh doesn't ever seem to wake up. so i threw in the TIOCSPGRP calls to pass the tty pgrp to the su'd zsh... and that fixes it. it looks like bash calls TIOCSPGRP directly to set the tty pgrp when it is continued... whereas zsh calls TIOCGPGRP to check it and then goes back to sleep because it doesn't own the tty. ugh. this is a gross... i'm leaning towards blaming zsh for the tty pgrp problems, but blaming su for the lack of setpgrp -- su really needs to protect itself from being put to sleep by its child accidentally. -dean --- shadow-4.0.3/src/su.c 2005-07-11 03:23:29.0 -0700 +++ shadow-4.0.3.dg1/src/su.c 2005-07-11 03:21:08.0 -0700 @@ -70,6 +70,7 @@ #include getopt.h #include pwauth.h #include getdef.h +#include sys/ioctl.h /* * Assorted #defines to control su's behavior @@ -751,14 +752,19 @@ exit(1); case 0: /* child */ signal(SIGINT, SIG_DFL); + if (setpgrp()) { + exit(1); + } break; default: /* parent */ + ioctl(0, TIOCSPGRP, pid); do { errno = 0; wpid = waitpid(pid, status, WUNTRACED); if (wpid == pid WIFSTOPPED(status)) { /* stop when child stops */ raise(SIGSTOP); + ioctl(0, TIOCSPGRP, pid); /* wake child when resumed */ kill(pid, SIGCONT); } -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh
tags 317747 confirmed thanks On Mon, 11 Jul 2005 02:08:26 -0700 (PDT) dean gaudet [EMAIL PROTECTED] wrote: this bug has been introduced since 1:4.0.3-35 ... perhaps related to the fix for #314727. This claim needs to be verified. with zsh as your shell, this sequence is busted: I see another symptome, fg only works after having been run for second time (race condition -- we have different timing here, your child shell gets control and then gets stopped. Mine doesn't have a chance to get control, it gets stopped before). Also, I see this only for `su -m` to root. When I e.g. `su -m builder`, everything works OK. the problem doesn't seem to happen if i drop the -m, or if i use bash or tcsh as the shell instead... the latter might point to this being a zsh problem, but it is a new thing since -35 and zsh hasn't changed, so i figured i'd start here. First I'll check whether it's actually new since -35. IMHO, this may be signal handling bug in zsh. I'm susrprised by your claim that suspend worked with -35, because CLOSE_SESSIONS was already set to yes in that release... -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh
Hi! On Mon, 11 Jul 2005 03:32:17 -0700 (PDT) dean gaudet [EMAIL PROTECTED] wrote: at first i tried just adding the setpgrp... You mean if(setpgrp()) exit(1);? but with that the su'd zsh doesn't ever seem to wake up. so i threw in the TIOCSPGRP calls to pass the tty pgrp to the su'd zsh... and that fixes it. Thanks for your time and good analysis. it looks like bash calls TIOCSPGRP directly to set the tty pgrp when it is continued... whereas zsh calls TIOCGPGRP to check it and then goes back to sleep because it doesn't own the tty. You have done my job. ;) ugh. this is a gross... i'm leaning towards blaming zsh for the tty pgrp problems, but blaming su for the lack of setpgrp -- su really needs to protect itself from being put to sleep by its child accidentally. This will be done but in other way -- just by ignoring TSTP. Is this OK with you? -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh
On Mon, 11 Jul 2005 03:07:15 -0700 (PDT) dean gaudet [EMAIL PROTECTED] wrote: both pids 4788 and 4789 have pgrp 4788. when zsh suspends itself it sends SIGTSTP to -4788. this TSTP hits both zsh(4789) and su(4788) -- which causes zsh(4782) to finish its waitpid (it was waiting on su(4788)). Your analysis is good. note that su(4788) has been stopped here *before* it issues raise(SIGSTOP). You mean it's stopped between waitpid() and raise()? Will 'su' ever see EINTR after waitpid() (because of TSTP)? then a while later when you type fg in zsh(4782), it sends a CONT to -4788, which wakes both 4788 and 4789... AFAIU bash sends CONT to 4788. Does zsh really send to -4788? now unfortunately the su continues on in the new 356_su-stop_cont-proxy patch ... it finally gets to do its raise(SIGSTOP)... and presto, that wakes up zsh(4782) again... and now both zsh processes are awake and fighting for the tty. OK. I saw this behaviour too (one time). But most of the time I see the next: penguin% su -m penguin# suspend zsh: suspended su -m penguin% fg [1] + continued su -m zsh: suspended (signal) su -m penguin% id uid=1016(xrgttn) gid=1016(xrgttn) groups=133(wheel),1016(xrgttn) penguin% fg [1] + continued su -m penguin# id uid=0(root) gid=0(root) groups=0(root) i think su should be creating a new process group for its child... As I already said, I'd just prefer to block/ignore several signals like TSTP. Most probably I'll do the same as in upstream -- block everything (except TERM and ALRM) until exit... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh
tags 317747 pending thanks As I already said, I'd just prefer to block/ignore several signals like TSTP. I did the same as in src/newgrp.c in our current shadow. I don't currently want to use sigprocmask() in su. Most probably I'll do the same as in upstream Hopefully we will release an experimental shadow 4.0.10 and then 4.0.11, where the things are done that way. -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317747: [Pkg-shadow-devel] Bug#317747: su -m / suspend / fg broken with zsh
On Mon, 11 Jul 2005, Alexander Gattin wrote: As I already said, I'd just prefer to block/ignore several signals like TSTP. Most probably I'll do the same as in upstream -- block everything (except TERM and ALRM) until exit... yeah after i stopped hacking and went to bed this popped into my head too... definitely a better solution :) -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]