linux-kernel - tty session leader issue (was Re: 2.6.25.3: su gets stuck for root)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <486BC30C.6010705@skyrush.com>
Date:	Wed, 02 Jul 2008 13:03:56 -0500
From:	Joe Peterson <joe@...rush.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
CC:	Alan Cox <alan@...hat.com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Newall <davidn@...idnewall.com>,
	Willy Tarreau <w@....eu>,
	Harald Dunkel <harald.dunkel@...nline.de>,
	linux-kernel@...r.kernel.org, tconnors@...her.puzzling.org
Subject: tty session leader issue (was Re: 2.6.25.3: su gets stuck for root)

I have done some more investigation on this problem, and I am posting
here my results in hope that someone can point me in the right direction
for further investigation...

Summary: during the initialization of a new bash shell, the terminal
foreground process group often reverts back to that of the parent of the
bash shell (after being set *to* the bash shell pgrp by bash),
prohibiting commands like stty from being run by the init scripts.  The
result is that the execution of these commands will hang until killed,
causing the bash prompt to not appear.  Adding a delay in the script
(using sleep) increases the chance of this having time to happen.

For example, putting the following in a user's .bashrc:

sleep 2
stty -ixany

is a good way to reproduce this.  doing "su <user>" from root (note that
the fact that no password is required helps the timing) will then often
hang.  Killing -9 stty will allow the bash prompt to appear.

I have instrumented the bash source code in an attempt to see why this
is happeneing, partly because I suspected a bug in bash.  What I have
found is this:

1) bash calls tcsetpgrp() with the pgrp of the bash process (two times)
before starting to execute init scripts.  This makes sense, since bash
needs to be the session leader.  It is never called again until just
before the bash shell exits normally (at which time it returns control
to the parent).

2) During the processing of the init scripts (sometimes .bashrc, but
sometimes a system script that is processed first), calling tcgetpgrp()
shows that the pgrp has reverted back to the "su <user>" process.  It
does not appear that bash reverted it in my testing so far.  Running
stty while in the reverted state causes a hang, since bash is not the
session leader.

So here is the question: is there a way/reason the kernel would revert
the pgrp of the session leader after bash sets it?  Is there some more
instrumenting in the kernel or in bash that might reveal what is going
on?  I have heard yet another report of this happening since I added to
the thread, and I can get it to happen easily on two different machines
(a desktop and a laptop).

						Thanks, Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/