archive mirror
 help / color / mirror / Atom feed
From: Aleksa Sarai <>
To: Andy Lutomirski <>
Cc:, Aleksa Sarai <>,
	Al Viro <>,
	Jeff Layton <>,
	"J. Bruce Fields" <>,
	Arnd Bergmann <>,
	David Howells <>,
	"Eric W. Biederman" <>,
	Christian Brauner <>,
	Linux API <>,
	Jann Horn <>,
	David Drysdale <>,
	Linux Containers <>,
	Linux FS Devel <>,
	LKML <>,
	linux-arch <>
Subject: Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags
Date: Sat, 24 Nov 2018 03:52:12 +1100	[thread overview]
Message-ID: <20181123165212.xldikl55iwcy4hyq@mikami> (raw)
In-Reply-To: <20181123164819.skruu23wjwzf47f5@mikami>

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

On 2018-11-24, Aleksa Sarai <> wrote:
> > >> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote:
> > >> * O_BENEATH: Disallow "escapes" from the starting point of the
> > >>  filesystem tree during resolution (you must stay "beneath" the
> > >>  starting point at all times). Currently this is done by disallowing
> > >>  ".." and absolute paths (either in the given path or found during
> > >>  symlink resolution) entirely, as well as all "magic link" jumping.
> > >
> > > With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be
> > > necessary?
> > 
> > This discussion reminds me of something I’m uncomfortable with in the
> > current patches: currently, most of the O_ flags determine some
> > property of the returned opened file.  The new O_ flags you're adding
> > don't -- instead, they affect the lookup of the file.  So O_BENEATH
> > doesn't return a descriptor that can only be used to loop up files
> > beneath it -- it just controls whether open(2) succeeds or fails.  It
> > might be nice for the naming of the flags to reflect this.
> I agree that there is something quite weird about having path resolution
> flags in an *open* syscall. The main reason why it's linked to open is
> because that's the only way to get O_PATH descriptors (which is what you
> would use for most of the extended operations we need -- as well as
> reading+writing to files which is what most users would do with this).
> And I think O_PATH is another example of an open flag that is just odd
> in how it changes the semantics of using open(2).
> One of the ideas I pitched in an earlier mail was a hypothetical
> resolveat(2) -- which would just be a new way of getting an O_PATH
> descriptor. This way, we wouldn't be using up more O_* flag bits with
> this feature and we'd be able to play with more radical semantic changes
> in the future. I can outline these here if you like, but it's a bit of a
> long discussion and I'd prefer not to derail things too much if
> resolveat(2) is definitely out of the question.

Sorry, one thing I forgot to mention about returning descriptors that
can only look up files beneath it -- while I think this would be very
useful, I'd be worried about jumping into chroot(2) territory where now
you are giving userspace the opportunity to try to create nested
"beneathfds" and so on. I do think it would be quite useful and
interesting though, but I'm not entirely sure how doable it would be
with the current namei infrastructure.

Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-11-23 16:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 14:26 [PATCH v4 0/4] namei: O_* flags to restrict path resolution Aleksa Sarai
2018-11-12 14:26 ` [PATCH v4 1/4] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2018-11-12 14:26 ` [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2018-11-23 12:10   ` Jürg Billeter
2018-11-23 16:07     ` Andy Lutomirski
2018-11-23 16:48       ` Aleksa Sarai
2018-11-23 16:52         ` Aleksa Sarai [this message]
2018-11-23 16:58     ` Aleksa Sarai
2018-11-12 14:26 ` [PATCH v4 3/4] namei: O_THISROOT: chroot-like path resolution Aleksa Sarai
2018-11-12 14:26 ` [PATCH v4 4/4] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai

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:

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

  git send-email \
    --in-reply-to=20181123165212.xldikl55iwcy4hyq@mikami \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).