Re: Weird kernel 2.6.17.[67] behaviour

[seb@frankengul.org]

On Thu, Jul 27, 2006 at 12:41:56AM +0100, Adam Henley wrote:
> On 27/07/06, Sébastien Bernard <seb@frankengul.org> wrote:
> >seb@frankengul.org a écrit :
> >> I got a perfectly workable kernel 2.6.17.1 using mkinitramfs on my U60.
> >>
> >> Can you shed some lights on this dark corner of linux ?
> >>
> >>       Seb
> 
> I can't shed any more light on it, but I can look too :o)

:). It was just a poetic licence.

> 
> The original mailing of the patch to the list is below:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0607.1/1694.html
> 
> [snip>
> The prctl() system call should never allow to set "dumpable" to the
> value 2. Especially not for non-privileged users.
> 
> This can be split into three cases:
>  1) running as root -- then core dumps will already be done as root,
>     and so prctl(PR_SET_DUMPABLE, 2) is not useful
>  2) running as non-root w/setuid-to-root -- this is the debatable case
>  3) running as non-root w/setuid-to-non-root -- then you definitely
>     do NOT want "dumpable" to get set to 2 because you have the
>     privilege escalation vulnerability
> <snip]
> 
> Is it that something else is misbehaving and trying to dump core as root?
> 

Well, I'm not arguing that the fix is a wrong fix.

I'm seeing that, on sparc64-smp arch with debian etch, this patch causes
a very strange sideeffect I was describing in my first mail.

The boot hangs, the cursor (in the framebuffer) stops blinking, nothing
is displayed, and the machine seems frozen until I hit a key or a button
mouse (which is on sparc causing the same interruption), and then the
machine resume the boot sequence as if nothing really happened.

I've been able to isolate that line to be the origin of this behaviour
but it could be as well a bug revealed by this modification.

	Seb