Re: [GIT PULL] execve updates for v6.13-rc1 (take 2)

From: Vegard Nossum
Date: Fri Nov 29 2024 - 16:43:32 EST



On 29/11/2024 05:44, Linus Torvalds wrote:
On Thu, 28 Nov 2024 at 19:34, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:

Just one thing - IMO we want to use the relative pathname when it's
not empty. Even in execveat()

Oh, absolutely agreed.

Good catch, because yes, I messed that part up in my suggested patch at

https://lore.kernel.org/all/CAHk-=wjF_09Z6vu7f8UAbQVDDoHnd-j391YpUxmBPLD=SKbKtQ@xxxxxxxxxxxxxx/

which did this dentry name thing for anything that used a base fd, but
yes, as you say, it should only do it when there is no name at all.

So instead of basing it (incorrectly) on that existing

if (fd == AT_FDCWD || filename->name[0] == '/') {

test, the logic should probably look something like

if (!filename->name[0]) {
rcu_read_lock();
strscpy(bprm->comm,
smp_load_acquire(&file->f_path.dentry->d_name.name));
rcu_read_unlock();
} else
strscpy(bprm->comm, kbasename(filename->name));

and it probably wouldn't be a bad idea to separate this out to be a
helper function that just does this one thing.

Probably a silly question, but why not do the same thing in all cases?
file->f_path.dentry->d_name.name _is_ the basename of whatever the
normal path resolution machinery ended up with; why not use just it
unconditionally? It handled empty paths already. This also seems to
match what you wrote in https://lore.kernel.org/all/CAHk-=wgKgi5eqo6oW0bBS2-Cr+d4jraoKfVq6wbmdiWWsZbMLw@xxxxxxxxxxxxxx/ (no argv[0], no magic strings, no symlinks):

dentry->d_name really *IS* the name of the file that is associated with the 'fd'.

Vegard