[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F065704.4020306@redhat.com>
Date: Thu, 05 Jan 2012 21:05:56 -0500
From: Rik van Riel <riel@...hat.com>
To: Kees Cook <keescook@...omium.org>
CC: Nick Bowler <nbowler@...iptictech.com>,
linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Federica Teodori <federica.teodori@...glemail.com>,
Lucian Adrian Grijincu <lucian.grijincu@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Eric Paris <eparis@...hat.com>,
Randy Dunlap <rdunlap@...otime.net>,
Dan Rosenberg <drosenberg@...curity.com>,
linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2012.1] fs: symlink restrictions on sticky directories
On 01/05/2012 03:55 PM, Kees Cook wrote:
> On Thu, Jan 5, 2012 at 12:08 PM, Nick Bowler<nbowler@...iptictech.com> wrote:
>> But this is a brand new feature that changes longstanding behaviour of
>> various syscalls. Making it default to enabled is rather mean to users
>> (since it will tend to get enabled by "oldconfig") and seems almost
>> guaranteed to cause regressions.
>
> I couldn't disagree more. There has been zero evidence of this change
> causing anything but regressions in _attacks_. :P If anything, I think
> there should be no CONFIG and no sysctl, and it should be entirely
> non-optional. But since this patch needs consensus, I have provided
> knobs to control it.
I agree with you, Kees.
The behaviour introduced by this patch should produce so
few issues, that the new behaviour should probably be on
by default.
The few people impacted can use a sysctl knob to disable
the check on their systems. I am not sure anyone will
actually be using that knob...
The config option is probably not needed. The new
behaviour is something that could just be on by default
for everyone, and disabled by the few (if any) people
who have some setup that breaks with it.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists