Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755740Ab2EJBNb (ORCPT ); Wed, 9 May 2012 21:13:31 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:40312 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751842Ab2EJBNa convert rfc822-to-8bit (ORCPT ); Wed, 9 May 2012 21:13:30 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Wed, 9 May 2012 18:13:08 -0700 X-Google-Sender-Auth: lnpDoOCSU2tu0kwxxIna3qxX_NY Message-ID: Subject: Re: setuid and RLIMIT_NPROC and 3.1+ To: =?ISO-8859-2?Q?Maciej_=AFenczykowski?= Cc: James Morris , Neil Brown , Vasiliy Kulikov , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 45 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 wrote: > On Wed, May 9, 2012 at 5:47 PM, Maciej Żenczykowski > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/