From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754817Ab0FAHzl (ORCPT ); Tue, 1 Jun 2010 03:55:41 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:52069 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753401Ab0FAHzh (ORCPT ); Tue, 1 Jun 2010 03:55:37 -0400 Date: Tue, 1 Jun 2010 03:55:29 -0400 From: Christoph Hellwig To: Kees Cook Cc: James Morris , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Randy Dunlap , Andrew Morton , Jiri Kosina , Dave Young , Martin Schwidefsky , Eric Paris , David Howells , Ingo Molnar , Peter Zijlstra , "Eric W. Biederman" , Tim Gardner , "Serge E. Hallyn" Subject: Re: [PATCH v2] fs: block cross-uid sticky symlinks Message-ID: <20100601075529.GA11397@infradead.org> References: <20100531030402.GQ6056@outflux.net> <20100531103510.GA30021@infradead.org> <20100531175733.GD4098@outflux.net> <20100601032423.GL4098@outflux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100601032423.GL4098@outflux.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 31, 2010 at 08:24:23PM -0700, Kees Cook wrote: > Well, that's what I'm trying to understand. It sounds like there is some > general agreement that the issue needs to be solved, but some folks do not > want it in the core VFS. As in, the objections aren't with how symlink > behavior is changed, just that the changes would be in the fs/ directory. No, it's not. It's not a change we can make for the default that everyone uses. If you're keen to mess up installations you control (aka ubuntu valuedadd viper) push it into a special LSM or rather a non-standard rule for it. It really doesn't matter if it's in fs/ or security/ but it's simplify not going to happen by default. > My rationale is that if it's in commoncaps, it's effective for everyone, so > it might as well be in core VFS. If the VFS objections really do boil down > to "not in fs/" then I'm curious if doing this in commoncaps is acceptable. If you think the objection is about having things in fs/ you're smoking some really bad stuff.