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

[Vegard Nossum]

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