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