From: Stefan Metzmacher <metze@samba.org>
To: David Howells <dhowells@redhat.com>, linux-api@vger.kernel.org
Cc: viro@zeniv.linux.org.uk, torvalds@linux-foundation.org,
cyphar@cyphar.com, christian.brauner@ubuntu.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] Mark AT_* path flags as deprecated and add missing RESOLVE_ flags
Date: Thu, 5 Mar 2020 21:11:25 +0100 [thread overview]
Message-ID: <4e915f46-093b-c566-1746-938dbd6dcf62@samba.org> (raw)
In-Reply-To: <3774367.1583430213@warthog.procyon.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2851 bytes --]
Hi David,
> Do we want to do this? Or should we duplicate the RESOLVE_* flags to AT_*
> flags so that existing *at() syscalls can make use of them?
>
> David
> ---
> commit 448731bf3b29f2b1f7c969d7efe1f0673ae13b5e
> Author: David Howells <dhowells@redhat.com>
> Date: Thu Mar 5 17:40:02 2020 +0000
>
> Mark AT_* flags as deprecated and add missing RESOLVE_ flags
>
> It has been suggested that new path-using system calls should use RESOLVE_*
> flags instead of AT_* flags, but the RESOLVE_* flag functions are not a
> superset of the AT_* flag functions. So formalise this by:
>
> (1) In linux/fcntl.h, add a comment noting that the AT_* flags are
> deprecated for new system calls and that RESOLVE_* flags should be
> used instead.
>
> (2) Add some missing flags:
>
> RESOLVE_NO_TERMINAL_SYMLINKS for AT_SYMLINK_NOFOLLOW
> RESOLVE_NO_TERMINAL_AUTOMOUNTS for AT_NO_AUTOMOUNT
> RESOLVE_EMPTY_PATH for AT_EMPTY_PATH
For me "TERMINAL" sounds strange here (I'm not a native speaker, so feel
free to ignore me...). I'd use "BASENAME" instead.
> (3) Make openat2() support RESOLVE_NO_TERMINAL_SYMLINKS. LOOKUP_OPEN
> internally implies LOOKUP_AUTOMOUNT, and AT_EMPTY_PATH is probably not
> worth supporting (maybe use dup2() instead?).
>
> Reported-by: Stefan Metzmacher <metze@samba.org>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Aleksa Sarai <cyphar@cyphar.com>
>
> diff --git a/fs/open.c b/fs/open.c
> index 0788b3715731..6946ad09b42b 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -977,7 +977,7 @@ inline struct open_how build_open_how(int flags, umode_t mode)
> inline int build_open_flags(const struct open_how *how, struct open_flags *op)
> {
> int flags = how->flags;
> - int lookup_flags = 0;
> + int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
> int acc_mode = ACC_MODE(flags);
>
> /* Must never be set by userspace */
> @@ -1055,8 +1055,8 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)
>
> if (flags & O_DIRECTORY)
> lookup_flags |= LOOKUP_DIRECTORY;
> - if (!(flags & O_NOFOLLOW))
> - lookup_flags |= LOOKUP_FOLLOW;
> + if (flags & O_NOFOLLOW)
> + lookup_flags &= ~LOOKUP_FOLLOW;
>
> if (how->resolve & RESOLVE_NO_XDEV)
> lookup_flags |= LOOKUP_NO_XDEV;
> @@ -1068,6 +1068,8 @@ inline int build_open_flags(const struct open_how *how, struct open_flags *op)
> lookup_flags |= LOOKUP_BENEATH;
> if (how->resolve & RESOLVE_IN_ROOT)
> lookup_flags |= LOOKUP_IN_ROOT;
> + if (how->resolve & RESOLVE_NO_TERMINAL_SYMLINKS)
> + lookup_flags &= ~LOOKUP_FOLLOW;
Where's the RESOLVE_NO_TERMINAL_AUTOMOUNTS check?
metze
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-03-05 20:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-05 17:43 David Howells
2020-03-05 20:11 ` Stefan Metzmacher [this message]
2020-03-05 20:35 ` David Howells
2020-03-06 14:56 ` David Howells
2020-03-06 13:56 ` Christian Brauner
[not found] ` <20200306134116.qfa2gj6os4weru7o@yavin>
2020-03-06 14:10 ` Christian Brauner
2020-03-06 14:43 ` David Howells
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=4e915f46-093b-c566-1746-938dbd6dcf62@samba.org \
--to=metze@samba.org \
--cc=christian.brauner@ubuntu.com \
--cc=cyphar@cyphar.com \
--cc=dhowells@redhat.com \
--cc=linux-api@vger.kernel.org \
--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
all inboxes | Powered by JetHome®