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: <19f34abd0806140045l259bcb93ie4b7bfa2d73bd4d@mail.gmail.com>
Date:	Sat, 14 Jun 2008 09:45:17 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Joe Peterson" <joe@...rush.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
Subject: Re: 2.6.25.3: su gets stuck for root

On Sat, Jun 14, 2008 at 3:49 AM, Joe Peterson <joe@...rush.com> wrote:
> Vegard Nossum wrote:
>> I think knowing the pgrps of the above processes (there is possibly
>> one more involved, stty?) would be useful; try:
>>
>>     $ ps -eo pid,pgrp,tpgid,user,args
>
> OK, I performed this test again (getting the su to hang), and here is
> the info:

[snip]

> scorpius ~ # ps -eo pid,pgrp,tpgid,user,args | grep 7036
>  6902  6902  7036 root     /bin/login --
>  6922  6922  7036 root     -bash
>  7036  7036  7036 foo      su foo
>  7037  7037  7036 foo      bash
>  7042  7037  7036 foo      stty -ixany

So this clearly shows what's wrong; 7036 is the "controlling process"
group id. But only "su foo" is in this group, the bash and stty
processes have their own group, 7037.

On my own system, when I do "su", I get this:
 2891  2891  2892 root     su temp
 2892  2892  2892 temp     bash

...and here the "bash" process is in the right group, 2892, while "su"
is the one in the background!

Can you try to run strace on the su to see where things go wrong, i.e.

    $ strace -f -e trace=process su foo

...and we're only interested in what happens up to the point where it
hangs. That should hopefully tell us which process is doing the wrong
thing. In either case, as Alan pointed out, this seems unlikely to be
a kernel problem.

[snip]

>> so can you please look for anything like that in your login scripts or
>> shell rc files?
>
> I do use stty in my .bashrc (that's why this happens), but I do not put
> it in the background.

Yeah, most likely the process that calls stty is first put in the
background itself (or never brought to the foreground?). But I don't
know why... when you get the trace, we can compare and find out where
it deviates.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/