Re: [PATCH v3 1/2] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case

[Tycho Andersen <tycho@tycho.pizza>]

On Wed, Oct 02, 2024 at 01:45:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Oct 01, 2024 at 08:42:56PM +0200, Aleksa Sarai wrote:
> > On 2024-10-01, Tycho Andersen <tycho@tycho.pizza> wrote:
> > > From: Tycho Andersen <tandersen@netflix.com>
> > > 
> > > Zbigniew mentioned at Linux Plumber's that systemd is interested in
> > > switching to execveat() for service execution, but can't, because the
> > > contents of /proc/pid/comm are the file descriptor which was used,
> > > instead of the path to the binary. This makes the output of tools like
> > > top and ps useless, especially in a world where most fds are opened
> > > CLOEXEC so the number is truly meaningless.
> > > 
> > > Change exec path to fix up /proc/pid/comm in the case where we have
> > > allocated one of these synthetic paths in bprm_init(). This way the actual
> > > exec machinery is unchanged, but cosmetically the comm looks reasonable to
> > > admins investigating things.
> > 
> > While I still think the argv[0] solution was semantically nicer, it
> > seems this is enough to fix the systemd problem for most cases and so we
> > can revisit the argv[0] discussion in another 10 years. :D
> 
...

> Unfortunately, I don't think that the approach with
> f_path.dentry->d_name.name can be used :(

hmm. Somehow earlier I had managed to convince myself that this gives
the right answer for symlinks too (instead of the original
kbasename(__d_path(file->f_path, root, buf, buflen)), but now upon
retesting it doesn't. So I agree, seems like the argv[0] hack is
needed unfortunately.

Tycho