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 for Android: free password hash cracker in your pocket

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

Message-ID: <48540343.4010200@skyrush.com>
Date:	Sat, 14 Jun 2008 11:43:31 -0600
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
Subject: Re: 2.6.25.3: su gets stuck for root

Vegard Nossum wrote:
> 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!

Hmm.

> 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.

OK, I attached this as a text file at the end.  But (*bummer*), using
strace makes it impossible to reproduce the hang (figures, and I believe
someone earlier in the thread also had this problem).

As for whether the kernel is at fault, not sure (i.e. does this hang
behavior implicate the kernel automatically or can a user-space process
cause itself such an issue?).  But I *do* see different behavior
depending on the kernel version.  There were a couple of git kernels in
which I could not reproduce it.  Still, if it is a race or something, it
might be that the conditions were just slightly perturbed.

I attached the strace log just in case it is of help.

					-Joe

View attachment "su_strace.log" of type "text/x-log" (2502 bytes)