On Sun, May 04, 2008 at 10:14:26AM +0800, [EMAIL PROTECTED] wrote: [...] > SC> Have you tried changing nobody's shell? > I don't want to.
Then, can you try: su - nobody -c ksh su - nobody -c pdksh su - nobody -c zsh Also, what about: perl -e '$<=$>=$(=$)=65534; exec sh' perl -e '$<=$>=$(=$)=65534; system sh' > CR> Does su do anything with process groups? > That is an advanced question not for little me. Not as far as the strace output can tell. > Anyway, the only other human to have reproduced any of this mess is > http://bugs.debian.org/476519#52 > Nobody :-) has responded to the points of that message #52. The poster seems to say that what makes a difference is what *root* does before calling su. That would be /etc/bash_completion? Not sure how what bash_completion does could have an impact on su. You've already ruled out the environment by running "env -i", you could check the open files with lsof -p "$$", you've already checked stty -a. You could try running ps to see if it left some processes running behind. I see "mesg n" in Sven's post. That command is meant to change the tty permissions to allow writes to the owner only, in that case root, but I can't see how that could affect nobody's sh. For sh to get a SIGTTIN upon the "read", it would have not to be in the foreground process group of the terminal. bash does put itself in the foreground process group by a: ioctl(255, TIOCSPGRP, getpid()) 255 being a dup(dup(2)). And it reads from 0. So one way to get that behavior could be if stderr is redirected to a different terminal as stdin... seems like a bit far fetched. running out of ideas here... -- Stéphane
