It doesn't make sense to worry about multicall binaries.

Posted Nov 27, 2024 18:25 UTC (Wed) by ebiederm (subscriber, #35028)
In reply to: Sad outcome by mezcalero
Parent article: The kernel's command-line commotion

For a multicall binary to check anything other than argv (to decide it's behavior) is against unix convention, it is impossible on other unices, and reading task comm is slower than reading argv0.

AKA that would be a stupid bug.

Plus for a multicall binary can reasonably be hardlinked, instead of symlinked. Which would be fewer resources in the filesystem and faster to start up.

The only case worth worrying about are process management things like ps that naturally read task->comm.

It doesn't make sense to worry about multicall binaries.

Posted Dec 4, 2024 9:57 UTC (Wed) by maxfragg (guest, #122266) [Link] (1 responses)

all true, but the output of ps and co suddenly becomes a lot less useful, when half of you system shows up as toybox/busybox instead of sh, sleep, cat, ....

It doesn't make sense to worry about multicall binaries.

Posted Dec 13, 2024 12:17 UTC (Fri) by roblucid (guest, #48964) [Link]

Hmmmm, less useful unless you're interested in the truth of it ..
execve(2) behaviour was not changing, in the fexecve(2) case if you're not willing to pay some cost as you are wanting to see a file with a verified signature why are you bothering with the file descriptor? If say you have written a shell with fexecve(2) support as a feature, surely you can set up an environment variable and do more smoke & mirrors processing on ps(1)/top(1) via builtin to protect users from their illusions being shattered.
Scripts have trace features to help debugging, couldn't you just turn off the use of fexecve when developing if necessary?
As somebody said allowing obfuscation of what you are really running seems to be to the benefit the "shenanigans" use case.