From: Linus Torvalds <firstname.lastname@example.org>
To: Aleksa Sarai <email@example.com>
Cc: Al Viro <firstname.lastname@example.org>,
Jeff Layton <email@example.com>,
"J. Bruce Fields" <firstname.lastname@example.org>,
Arnd Bergmann <email@example.com>,
David Howells <firstname.lastname@example.org>,
Christian Brauner <email@example.com>,
Eric Biederman <firstname.lastname@example.org>,
Andy Lutomirski <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Alexei Starovoitov <email@example.com>,
Kees Cook <firstname.lastname@example.org>, Jann Horn <email@example.com>,
Tycho Andersen <firstname.lastname@example.org>,
David Drysdale <email@example.com>,
Chanho Min <firstname.lastname@example.org>, Oleg Nesterov <email@example.com>,
Aleksa Sarai <firstname.lastname@example.org>,
Linux Containers <email@example.com>,
Linux API <firstname.lastname@example.org>,
Linux List Kernel Mailing <email@example.com>,
Subject: Re: [PATCH v7 5/5] namei: resolveat(2) syscall
Date: Fri, 24 May 2019 15:59:19 -0700 [thread overview]
Message-ID: <CAHk-=whbFMg4+HuWOBuHpvDNiAyowX2HUowv3+pt8vPWk5W-YQ@mail.gmail.com> (raw)
On Tue, May 7, 2019 at 9:44 AM Aleksa Sarai <firstname.lastname@example.org> wrote:
> The most obvious syscall to add support for the new LOOKUP_* scoping
> flags would be openat(2) (along with the required execveat(2) change
> included in this series). However, there are a few reasons to not do
So honestly, this last patch is what turns me off the whole thing.
It goes from a nice new feature ("you can use O_NOSYMLINKS to disallow
symlink traversal") to a special-case joke that isn't worth it any
more. You get a useless path descrptor back from s special hacky
system call, you don't actually get the useful data that you probably
*want* the open to get you.
Sure, you could eventually then use a *second* system call (openat
with O_EMPTYPATH) to actually get something you can *use*, but at this
point you've just wasted everybodys time and effort with a pointless
second system call.
So I really don't see the point of this whole thing. Why even bother.
Nobody sane will ever use that odd two-systemcall model, and even if
they did, it would be slower and inconvenient.
The whole and only point of this seems to be the two lines that say
if (flags & ~VALID_RESOLVE_FLAGS)
but that adds absolutely zero value to anything. The argument is that
"we can't add it to existing flags, because old kernels won't honor
it", but that's a completely BS argument, since the user has to have a
fallback anyway for the old kernel case - so we literally could much
more conveniently just expose it as a prctl() or something to _ask_
the kernel what flags it honors.
So to me, this whole argument means that "Oh, we'll make it really
inconvenient to actually use this".
If we want to introduce a new system call that allows cool new
features, it should have *more* powerful semantics than the existing
ones, not be clearly weaker and less useful.
So how about making the new system call be something that is a
*superset* of "openat()" so that people can use that, and then if it
fails, just fall back to openat(). But if it succeeds, it just
succeeds, and you don't need to then do other system calls to actually
make it useful.
Make the new system call something people *want* to use because it's
useful, not a crippled useless thing that has some special case use
for some limited thing and just wastes system call space.
Example *useful* system call attributes:
- make it like openat(), but have another argument with the "limit flags"
- maybe return more status of the resulting file. People very
commonly do "open->fstat" just to get the size for mmap or to check
some other detail of the file before use.
In other words, make the new system call *useful*. Not some castrated
"not useful on its own" thing.
So I still support the whole "let's make it easy to limit path lookup
in sane ways", but this model of then limiting using the result sanely
just makes me a sad panda.
next prev parent reply other threads:[~2019-05-24 23:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 16:43 [PATCH v7 0/5] namei: resolveat(2) path resolution restriction API Aleksa Sarai
2019-05-07 16:43 ` [PATCH v7 1/5] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-05-07 16:43 ` [PATCH v7 2/5] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-05-07 16:43 ` [PATCH v7 3/5] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-05-07 16:43 ` [PATCH v7 4/5] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-05-07 16:43 ` [PATCH v7 5/5] namei: resolveat(2) syscall Aleksa Sarai
2019-05-24 22:59 ` Linus Torvalds [this message]
2019-05-25 7:03 ` Aleksa Sarai
2019-05-25 16:54 ` Linus Torvalds
2019-05-26 5:46 ` Aleksa Sarai
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 \
* 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).