Re: setuid and RLIMIT_NPROC and 3.1+

[Linus Torvalds]

Oh christ, I also cannot be bothered to continue arguing with you
since you seemingly randomly drop other people from the discussion.

So don't expect any more replies from me.

                    Linus

On Wed, May 9, 2012 at 6:10 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, May 9, 2012 at 5:47 PM, Maciej Åenczykowski
> <zenczykowski@xxxxxxxxx> wrote:
>>
>> If you return EAGAIN from setuid, because we've run into the hard
>> limit, and userspace doesn't check it, then the exec will still
>> succeed, and we'll end up running the exec'ed code as root.
>
> But how would that happen in practice, and why would we care?
>
> If the application is buggy, it won't check the setuid() error return,
> but if it does the exec, it will fail.
>
> Only a buggy *and*malicious* application that *first* does non-exec
> cases up until it hits the hard limit and *then* tries to do a buggy
> setuid() - without testing the error value - and exec() would care.
>
> But we don't care about applications that *try* to be actively buggy.
> That simply isn't the interesting case. The point of the whole "return
> error at execve()" was not to discourage the actively buggy usage
> case, but the *accidentally* buggy case. And there's no sane way the
> accidentally buggy case can trigger what you describe.
>
> So the whole point wasn't that it "fixes" buggy applications (they
> are, after all, buggy), but that it makes it less likely to have
> accidental problems. It's a "softer" edge to some bugs.
>
> That said, I don't really care that much about the original patch
> either. For all I care, we could revert it. I just simply don't
> understand the point of your objections.
>
> Â Â Â Â Â Â Â Â Â Â Â Â ÂLinus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/