Thread (11 messages) 11 messages, 5 authors, 2020-03-12

Re: [PATCH 01/14] VFS: Add additional RESOLVE_* flags [ver #18]

flat view

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2020-03-10 01:14:24
Also in: linux-fsdevel, linux-security-module, lkml

On Mon, Mar 9, 2020 at 5:56 PM Aleksa Sarai [off-list ref] wrote:
On 2020-03-09, David Howells [off-list ref] wrote:
quoted
This is necessary for fsinfo() to use RESOLVE_* flags instead of AT_* flags
if the latter are to be considered deprecated for new system calls.

Also make openat2() handle RESOLVE_NO_TRAILING_SYMLINKS.
No, please let's not do this.

We have O_NOFOLLOW, and we can't get rid of it.

So adding RESOLVE_NO_TRAILING_SYMLINKS isn't a cleanup. It's just
extra complexity for absolutely zero gain.

After thinking about what Christian said some more, I reckon we
shouldn't support both O_NOFOLLOW and RESOLVE_NO_TRAILING_SYMLINKS. But
that means we'll need to cherry-pick this patch and get it into mainline
before v5.6.
No.

It simply means that we shouldn't have RESOLVE_NO_TRAILING_SYMLINKS at all.

Adding that flag is a mistake. It causes problems like this, where
subtlenly people say "what if both flags are set".

Just don't do it.

There's no way in hell we can ever get rid of O_NOFOLLOW anyway, since
people will continue to use plain open() and openat().

So adding RESOLVE_NO_TRAILING_SYMLINKS is entirely redundant.

Don't deprecate the old flags that are going to always stay around,
don't add stupid new flags that add no value.

It's that easy.

              Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help