Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Christian Brauner <christian@brauner.io>,
	David Drysdale <drysdale@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Tycho Andersen <tycho@tycho.ws>, Chanho Min <chanho.min@lge.com>,
	Oleg Nesterov <oleg@redhat.com>, Aleksa Sarai <asarai@suse.de>,
	containers@lists.linux-foundation.org,
	linux-alpha@vger.kernel.org, linux-api@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags
Date: Sat, 13 Jul 2019 03:41:53 +0100
Message-ID: <20190713024153.GA3817@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190712150026.GO17978@ZenIV.linux.org.uk>

On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
> On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
> 
> > 	if (flags & LOOKUP_BENEATH) {
> > 		nd->root = nd->path;
> > 		if (!(flags & LOOKUP_RCU))
> > 			path_get(&nd->root);
> > 		else
> > 			nd->root_seq = nd->seq;
> 
> BTW, this assignment is needed for LOOKUP_RCU case.  Without it
> you are pretty much guaranteed that lazy pathwalk will fail,
> when it comes to complete_walk().
> 
> Speaking of which, what would happen if LOOKUP_ROOT/LOOKUP_BENEATH
> combination would someday get passed?

I don't understand what's going on with ->r_seq in there - your
call of path_is_under() is after having (re-)sampled rename_lock,
but if that was the only .. in there, who's going to recheck
the value?  For that matter, what's to guarantee that the thing
won't get moved just as you are returning from handle_dots()?

IOW, what does LOOKUP_IN_ROOT guarantee for caller (openat2())?

  reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06 14:57 [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 01/10] namei: obey trailing magic-link DAC permissions Aleksa Sarai
2019-07-12  4:14   ` Al Viro
2019-07-12  6:36     ` Al Viro
2019-07-12 12:20     ` Aleksa Sarai
2019-07-12 13:10       ` Al Viro
2019-07-14  7:11         ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 02/10] procfs: switch magic-link modes to be more sane Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 03/10] open: O_EMPTYPATH: procfs-less file descriptor re-opening Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 04/10] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-07-12  4:20   ` Al Viro
2019-07-12 12:07     ` Aleksa Sarai
2019-07-12 12:12       ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 05/10] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-07-12  4:33   ` Al Viro
2019-07-12 10:57     ` Aleksa Sarai
2019-07-12 12:39       ` Al Viro
2019-07-12 12:55         ` Al Viro
2019-07-12 13:25           ` Al Viro
2019-07-12 15:00             ` Al Viro
2019-07-13  2:41               ` Al Viro [this message]
2019-07-14  3:58                 ` Al Viro
2019-07-16  8:03                   ` Aleksa Sarai
2019-07-14  7:00                 ` Aleksa Sarai
2019-07-14 14:36                   ` Al Viro
2019-07-18  3:17                     ` Aleksa Sarai
2019-07-14 10:31             ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 06/10] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 07/10] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 08/10] open: openat2(2) syscall Aleksa Sarai
2019-07-18 14:48   ` Rasmus Villemoes
2019-07-18 15:21     ` Aleksa Sarai
2019-07-18 15:10   ` Arnd Bergmann
2019-07-18 16:12     ` Aleksa Sarai
2019-07-18 21:29       ` Arnd Bergmann
2019-07-19  2:12         ` Dmitry V. Levin
2019-07-19 10:29           ` Christian Brauner
2019-07-19  1:59   ` Dmitry V. Levin
2019-07-19  2:19     ` Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 09/10] kselftest: save-and-restore errno to allow for %m formatting Aleksa Sarai
2019-07-06 14:57 ` [PATCH v9 10/10] selftests: add openat2(2) selftests Aleksa Sarai
2019-07-08  1:15   ` Michael Ellerman
2019-07-08  5:47     ` Aleksa Sarai
2019-07-12 15:11 ` [PATCH v9 00/10] namei: openat2(2) path resolution restrictions Al Viro
2019-07-12 15:32   ` Aleksa Sarai

Reply instructions:

You may reply publically 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=20190713024153.GA3817@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=asarai@suse.de \
    --cc=ast@kernel.org \
    --cc=bfields@fieldses.org \
    --cc=chanho.min@lge.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=dhowells@redhat.com \
    --cc=drysdale@google.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=jlayton@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=oleg@redhat.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tycho@tycho.ws \
    /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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org linux-fsdevel@archiver.kernel.org
	public-inbox-index linux-fsdevel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox