Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761295Ab2EIXuz (ORCPT ); Wed, 9 May 2012 19:50:55 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:47776 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760483Ab2EIXux convert rfc822-to-8bit (ORCPT ); Wed, 9 May 2012 19:50:53 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Wed, 9 May 2012 16:50:32 -0700 X-Google-Sender-Auth: 4koImgbbpt0_8NP-OVtNCMCAqcg Message-ID: Subject: Re: setuid and RLIMIT_NPROC and 3.1+ To: =?ISO-8859-2?Q?Maciej_=AFenczykowski?= Cc: Linux Kernel Mailing List , James Morris , Neil Brown , Vasiliy Kulikov 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: 1068 Lines: 25 On Wed, May 9, 2012 at 4:46 PM, Maciej Żenczykowski wrote: > > Doesn't that just reintroduce the security 'hole' in buggy userspace apps > that the original patch was attempting to fix? Well, those bggy apps have to be really *odd* buggy apps now. IOW, they need to do setuid(), and then not execve(). At that point, they really do have to check the error return, since there is no execve() for them to check. In the end, we can do only so much to counter buggy apps. I think my patch is a reasonable "we can try to give the error at execve() time, but if somebody does tons of setuid() without ever doing the execve(), at some point they do have to check the error return of setuid() itself". I suspect most users of setuid() are good and check the error return. 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/