Bug#317747: su -m / suspend / fg broken with zsh

2005-07-11 Thread dean gaudet
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

2005-07-11 Thread dean gaudet
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

2005-07-11 Thread dean gaudet
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

2005-07-11 Thread Alexander Gattin

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

2005-07-11 Thread Alexander Gattin

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

2005-07-11 Thread Alexander Gattin

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

2005-07-11 Thread Alexander Gattin

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

2005-07-11 Thread dean gaudet
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]