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]

Date:	Sat, 14 Jun 2008 14:52:05 -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:
> Yeah, a user-space process can do this, and it's the right behaviour
> for the kernel. I did post a program that would "reproduce" what
> you're seeing. I do now believe that it's something timing-related, as
> Alan suggested initially. (But timing-related with your scripts, that
> is. I must say, that "sleep 2" does look a bit suspicious; I have no
> idea what that is supposed to do :-))

Ah, that is something I put in there to artificially make it more
reproducible.  Here's the reason: when I first encountered the problem,
it was happening if the home dir of the user was on the "btrfs"
filesystem (the new checksumming one from Oracle).  This made me suspect
btrfs initially.  But I reproduced the problem [more sporadically] when
the home was on ext3 as well.  Since btrfs has a different performance
profile, especially when first accessed after a mount (and it is a
filesystem still under development, so some optimizations are yet to
come), I figured it might be timing-related, and sure enough, adding the
"sleep 2" proved that.

So without the sleep 2 and with a home of ext3, it rarely happens, since
it takes very little time to read the homedir files (.bashrc, etc.).
Putting in the sleep makes it almost always happen.  It seems like the
delay invoked by the sleep causes that subsequent stty call to hang.

> I suppose it would be more useful to see a trace where you include a
> few more system calls, can you try:
> 
>     # strace -e trace=process,ioctl,setpgid -f su foo
> 
> instead?

OK, attached.

> Just for the record, I'm probably not the best person to debug this,
> so I'm just trying to figure it out as we go. On the other hand, I
> don't see better suggestions from anybody else. Thank you for
> persisting, though! :-)
> 
> (And the fact that the results differ with the kernel versions does
> make this relevant for LKML still.)

Thanks for helping.  Yes, this is the kind of nagging issue that really
bugs me, since it is intermittent and makes things feel unstable.  If we
determine the problem is in something else (like stty or bash), then at
least I can file a bug with them.

						-Joe

View attachment "strace_su.log" of type "text/x-log" (5682 bytes)