linux-kernel - 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: <4857D92A.8040402@skyrush.com>
Date:	Tue, 17 Jun 2008 09:32:58 -0600
From:	Joe Peterson <joe@...rush.com>
To:	Alan Cox <alan@...hat.com>
CC:	Vegard Nossum <vegard.nossum@...il.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
Subject: Re: 2.6.25.3: su gets stuck for root

Alan Cox wrote:
> This looks correct to me and in fact I see the behaviour you report on 2.6.23
> when running it. If I tell it to ignore SIGTTOU that also then behaves as
> expected.
> 
> If
> 	your pgrp is not the pgrp of the tty
> 	and you are not ignoring TTOU
> 	and you are not orphaned (as a group)
> 
> 	Then we are *supposed* to send you SIGTTOU and kick you back
> 	into touch.

OK, I am still baffled.  I've thought of several different theories,
wondering if bash does not have the right parent process, how there
could be a race in the kernel or elsewhere, but as far as I can tell,
things are in order.  Here's the ps -ax --forest output while hung:

 6435 tty3     Ss     0:00 /bin/login --
 7954 tty3     S      0:00  \_ -bash
 7958 tty3     S+     0:00      \_ su foo
 7959 tty3     S      0:00          \_ bash
 7964 tty3     T      0:00              \_ stty -ixany

I had logged into the tty as root (with shell set to bash), then su'd to
foo (with shell set to bash), so this tree makes sense.  During the
sleep before the stty, sleep is under the final bash similar to the way
stty is while it is hung.

Note that the stty is a child of bash (which, BTW, sometimes appears as
"-su" instead - I am not clear on that), and they all lead back to the
original tty, which I gather is the session leader (or is it the "su"?).

Now, the debugging I did shows that the reason that tty_check_change()
returns an error is that the tty->pgrg != task_pgrp(current).  The
former is the "su foo" process, and the latter is the bash child process.

So I guess that when it does work, they are the same process, but why
would they be the same (or not, as it were)?  Does something happen
during bash startup that causes bash to become the session leader?

Please, please, someone who understands the mechanics better than I let
me know how I can explore this more deeply.

						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/