linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: James Morris <jmorris@namei.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	Randy Dunlap <rdunlap@xenotime.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Dave Young <hidave.darkstar@gmail.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Eric Paris <eparis@redhat.com>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Tim Gardner <tim.gardner@canonical.com>,
	"Serge E. Hallyn" <serue@us.ibm.com>
Subject: Re: [PATCH v2] fs: block cross-uid sticky symlinks
Date: Mon, 31 May 2010 20:24:23 -0700	[thread overview]
Message-ID: <20100601032423.GL4098@outflux.net> (raw)
In-Reply-To: <alpine.LRH.2.00.1006010904190.675@tundra.namei.org>

On Tue, Jun 01, 2010 at 09:09:10AM +1000, James Morris wrote:
> On Mon, 31 May 2010, Kees Cook wrote:
> 
> > Expecting the push-back from VFS, I wrote this patch against commoncaps.
> > 
> > James, would you take it there (along with the patch to SELinux to call
> > out to commoncaps) if there is no way to proceed with the VFS core towards
> > solving this?
> 
> Isn't this just bypassing the VFS objections?

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.

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.

Ironically, doing this in commoncaps is the patch I sent.  :P

To me, the VFS objections really seem like a obfuscated version of
"this should not be in the kernel in any way", which I think does not
admit to the problem existing in the first place.  Either there is a
problem or there isn't.  If there is a problem, it should be fixed.
I think there is a problem with the kernel semantics of symlinks.
Therefore, it should be fixed in the kernel.

I personally do not care if it's in fs/ or security/, I'm just seeking
the most efficient and complete solution.

-Kees

-- 
Kees Cook
Ubuntu Security Team

  reply	other threads:[~2010-06-01  3:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31  3:04 [PATCH v2] fs: block cross-uid sticky symlinks Kees Cook
2010-05-31  3:50 ` Eric W. Biederman
2010-05-31  4:12   ` Kees Cook
2010-05-31  3:54 ` Eric Paris
2010-05-31  4:23   ` Kees Cook
2010-05-31 10:23 ` Alan Cox
2010-05-31 17:50   ` Kees Cook
2010-05-31 18:09     ` Alan Cox
2010-05-31 19:07       ` Kees Cook
2010-05-31 19:52         ` Al Viro
2010-05-31 22:00           ` Kees Cook
2010-05-31 19:27     ` Al Viro
2010-05-31 10:35 ` Christoph Hellwig
2010-05-31 17:57   ` Kees Cook
2010-05-31 23:09     ` James Morris
2010-06-01  3:24       ` Kees Cook [this message]
2010-06-01  7:55         ` Christoph Hellwig
2010-06-01 11:55           ` Eric Paris
2010-06-01 14:52             ` Kees Cook
2010-06-01 15:34               ` Eric Paris
2010-06-01 17:31                 ` tytso
2010-06-01 15:00           ` Kees Cook
2010-05-31 10:47 ` tytso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100601032423.GL4098@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=hidave.darkstar@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jmorris@namei.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=serue@us.ibm.com \
    --cc=tim.gardner@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).