Messages in this thread |  | | From | Linus Torvalds <> | | Date | Wed, 27 Nov 2024 18:24:27 -0800 | | Subject | Re: [GIT PULL] execve updates for v6.13-rc1 (take 2) |
| |
On Wed, 27 Nov 2024 at 18:06, Al Viro <viro@zeniv.linux.org.uk> wrote: > > > So if pathname exists and isn't empty, AT_EMPTY_PATH does nothing. > > ... so let's tie that to pathname _being_ empty - it's not as if it > had been hard to check.
This is not some kind of new system call, and AT_EMPTY_PATH isn't some Linux-only thing.
It has well-defined and documented semantics:
AT_EMPTY_PATH If this flag is specified, oldname can be an empty string.
Note the "can be". Not "will/must be".
> What's more, let's allow userland pointer to be NULL - use getname_maybe_null() > and treat NULL returned by it as "we have an empty pathname".
Now, that's separate, and I agree with that extension. That just suppresses another "empty string" error case.
But no, I do not accept changing well-documented behaviour of AT_EMPTY_PATH, much less the insanity of making "execveat()" have completely different semantics for AT_EMPTY_PATH than a plain openat.
Linus
|  |