LKML Archive on
help / color / mirror / Atom feed
From: Aleksa Sarai <>
To: Al Viro <>
Cc: Ed Maste <>,
	David Drysdale <>,
Subject: Re: [PATCH v2 1/3] namei: implement O_BENEATH-style AT_* flags
Date: Sun, 28 Oct 2018 02:37:23 +1100	[thread overview]
Message-ID: <20181027153723.nfro756r4o2vxqqr@ryuk> (raw)
In-Reply-To: <>

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

On 2018-10-27, Al Viro <> wrote:
> On Sat, Oct 27, 2018 at 06:17:29PM +1100, Aleksa Sarai wrote:
> > I'm going to send out a v4 "soon" but I would like to know what folks
> > think about having resolveat(2) (or similar) to separate the scoping O_*
> > flags and produce an O_PATH -- since unsupported O_* flags are ignored
> > by older kernels userspace will have to do some plenty of checking after
> > each path operation.
> > 
> > Personally, I believe this (along with AT_EMPTY_PATH for openat(2))
> > would help with some other O_PATH issues.
> The trouble with resolveat(2) is that for anything directory-modifying
> you really want directory locked before the lookup for last component.
> IOW, funlink(2) are hopeless.

Ah, right... In those cases I think that AT_SYMLINK_NOFOLLOW could help,
or maybe we would need to have some of the scoping flags for other
syscalls (though this would be an issue in either case for scoping
unlinkat(2) -- even if we used O_BENEATH). :/

But my main issue at the moment with O_PATH is that /proc/self/fd/...
re-opening allows for some very odd delayed-access-check attacks.
openat(2) doesn't give you an O_EMPTYPATH but that is what you get with

For instance, take /proc/self/exe. Tautologically, it is impossible to
open it O_RDWR -- if you are resolving it through an "exe" magic symlink
then it is being used as a process's ->mm (and thus is locked from
writing). *However* you can open it O_PATH and then later re-open it
through /proc/self/fd. We had cases where a container runtime joining a
container would be able to do this and overwrite the container binary
*on the host*. This has been mitigated now (as part of CVE-2016-9962),
but I would be very shocked if there was no other places where this sort
of thing would happen.

My proposal for resolveat(2) would let us have some sort of "I want
these access bits" API for O_PATH. Of course there are some quite
not-nice changes I think you'd need to allow for this usecase -- my
back-of-the-envelope proposal would be to stash away the fmode bits
inside 'struct path' so that do_last() can see whether we are doing a
re-open of an existing 'struct file' (but I'm sure this sounds awful).

Is this a problem you think deserves solving / is there a better way of
going about it? Thanks.

Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH

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

      parent reply	other threads:[~2018-10-27 15:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09  6:52 [PATCH v2 0/3] namei: implement various lookup restriction AT_* flags Aleksa Sarai
2018-10-09  6:52 ` Aleksa Sarai
2018-10-09  6:52 ` [PATCH v2 1/3] namei: implement O_BENEATH-style " Aleksa Sarai
2018-10-09 19:25   ` Andy Lutomirski
2018-10-10  7:07     ` Aleksa Sarai
2018-10-10  7:28       ` Aleksa Sarai
2018-10-12  1:12       ` Andy Lutomirski
2018-10-27  1:41   ` Ed Maste
2018-10-27  7:17     ` Aleksa Sarai
2018-10-27  7:53       ` Al Viro
2018-10-27 12:11         ` : " Ed Maste
2018-10-27 15:37         ` Aleksa Sarai [this message]

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=20181027153723.nfro756r4o2vxqqr@ryuk \ \ \ \ \ \

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