[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713094856.GA20924@openwall.com>
Date: Wed, 13 Jul 2011 13:48:56 +0400
From: Solar Designer <solar@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: RLIMIT_NPROC check in set_user()
Vasiliy,
On Mon, Jul 11, 2011 at 10:56:35PM +0400, Vasiliy Kulikov wrote:
> On Mon, Jul 11, 2011 at 20:59 +0400, Solar Designer wrote:
> > After this is taken care of, please also consider other ways set*id()
> > syscalls might fail on errors unrelated to the process possessing
> > appropriate privileges. IIRC, set_user() could also fail when it's not
> > able to allocate an instance of "struct user" - unlikely, but possible.
> > I think the process must be killed on those errors. There's no better
> > action to take on them.
>
> As Spender has noticed, small allocations may not fail, they are forced
> to use __GFP_NOFAIL.
Oh, I now seem to recall that this was mentioned to me before (in an
LKML discussion a few years ago, but I failed to find it now). My
opinion on this was/is that if we have a "can't happen" condition -
set_user() failure - then this is yet another reason why we must not
merely return -EAGAIN on this condition. Rather, killing the process
would be a safer action to take. As long as our assumptions are
correct, it can't happen anyway. If/when the assumptions break (with a
code revision, or because we've overlooked something now), the safer
action will be taken (after my proposed change).
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
