linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS
Date: Mon, 20 Mar 2017 07:22:55 -0700	[thread overview]
Message-ID: <20170320142255.GA28475@vader> (raw)
In-Reply-To: <CA+55aFxgncZ76jcsB8R1bTV2nYpMVr_O_wy1Vx93JgGi6gXMhw@mail.gmail.com>

On Sun, Mar 19, 2017 at 06:46:01PM -0700, Linus Torvalds wrote:
> On Sun, Mar 19, 2017 at 10:24 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >         Bringing back an old conversation - what do you think about the
> > potential usefulness of the following ...at() option:
> >         * no mountpoint crossings allowed (mount --bind included)
> >         * only relative symlinks traversals are allowed
> >         * starting point acts as a chroot boundary (IOW, .. does not lead
> > out of it)
> 
> Hmm. The original use of this was iirc apache (or maybe samba), that
> simply wanted to be sure that when you did a pathname lookup, it
> didn't escape out of the subtree that the lookup was done from (eg
> some public_html directory or whatever).
> 
> But I had that discussions *long* ago, and I don't even remember who
> it might have been with. My reaction at the time was simply that it
> would have been easy for us to have a "no symlink traversal at all"
> mode, because their solution was to just walk each path component
> carefully by hand.
> 
> Maybe somebody who knows apache (or samba) can pipe up and say "yeah,
> we still do that", or "we solved it with our own filename cache, so we
> don't care".

The last posting of the O_BENEATH flag with very similar semantics
indicated that there were sandboxing usecases that still want this [1].
I think it's a good idea; the kernel is in the best place to do this
correctly instead of having a bunch of half-baked implementations in
userspace everywhere.

1: http://marc.info/?l=linux-fsdevel&m=143945842819081&w=2

  reply	other threads:[~2017-03-20 14:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-19 17:24 [RFC] AT_NO_JUMPS/LOOKUP_NO_JUMPS Al Viro
2017-03-20  1:46 ` Linus Torvalds
2017-03-20 14:22   ` Omar Sandoval [this message]
2017-05-02 19:57 ` Pavel Machek
2017-05-02 20:49   ` Al Viro

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=20170320142255.GA28475@vader \
    --to=osandov@osandov.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).