Simple solution

Posted Nov 28, 2024 8:04 UTC (Thu) by rrolls (subscriber, #151126)
Parent article: The kernel's command-line commotion

Add a new version of fexecve/execveat which takes an arbitrary string to be placed on `comm` in addition to the file descriptor.

Programs wishing to use this instead of execve, when the original path is a symlink, can get the basename of the original path themselves, do whatever opening and checking they like of the contents of the file, then pass that basename to be stored in `comm`.

Everyone wins.

to post comments

Simple solution

Posted Nov 28, 2024 11:27 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

Yes. Or even use the existing call, with a flag not to touch the comm altogether. That way the calling process could just: fork(); prctl(PR_SET_NAME, "lalala"); execveat(..., AT_KEEP_PR_NAME); and be done with it.

Simple solution

Posted Nov 29, 2024 14:04 UTC (Fri) by vbabka (subscriber, #91706) [Link]

Maybe even the pathname argument could be repurposed to become comm with AT_EMPTY_PATH (plus/or another new flag to control this new behavior), because normally it's an empty string with AT_EMPTY_PATH? That would avoid the need for prctl().

Simple solution

Posted Nov 28, 2024 20:22 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

That's basically the same idea as copying *argv, just a bit more complicated. /proc/self/comm is one of two things:

1. The (first 16 characters of the) file which was actually executed by the kernel.
2. A string the program which was executed passed as argument to PR_SET_NAME.

This means that it's not under control of the code which executed the exec system call. In contrast to this, *argv is the first string of the argument vector. By convention, this is also the filename of the executed file but that's really just a convention. It can be any string the executing process desired to use as first argument and it may even not exist at all, ie *argv may be NULL.

Copying *argv (or, for that matter, any other string the executing process can either chose freely or omit at all) thus doesn't solve the problem that, for programs executed via file descriptor, the correct comm value is useless for determining information about the actually running program.

There's no correct solution for setting comm to the value it would have had had execve with a filename been used instead of execveat/ fexecve because the name which was used to open the file descriptor may no longer refer to the same file by the time it's executed. Using the name from the dentry is probably the best approximation as that's at least a name referring to the file which is being executed.