Sad outcome

Posted Nov 28, 2024 4:15 UTC (Thu) by neilbrown (subscriber, #359)
In reply to: Sad outcome by mezcalero
Parent article: The kernel's command-line commotion

I agree that an fexecve2() that takes a "comm" argument would be a good thing. But it isn't necessary.

Just find some private directory, create a symlink from my_comm to /proc/self/fd/NN, make sure NN is CLOSE-ON-EXEC,
and
execveat(private-dir-fd, "my_comm", argv, envp, 0);

As close-on-exec is processed after the target file is opened, this gives you all you need.

Having to find a private directory isn't ideal, but shouldn't be too hard. /run/fexec/$UID/$PID/ ??
Cleaning up might be awkward.

Sad outcome

Posted Nov 28, 2024 8:32 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (1 responses)

Sure I can also copy the binary and rename it, and then glue a floppy disk to my forehead. It's a bit ridiculous to suggest this was a suitable method of operation for *all* service binary invocations while at the same time saying that initializing comm[] from argv[0] was not an option because doing such a memcpy() would be "too slow".

I mean, come on.

(Yes, I know it wasn't you who who said copying argv[0] → comm[] was too slow, that was Linus.)

Sad outcome

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

The difference is the cost is only paid by those debugging, not expose every user unwittingly to potential hostile shenanigans by relying on mutable user space variables. The people changing to use fexecve(2) for the security benefits should perhaps add a logging option saying what they're calling and what the child pid was.

I developed many years, then later ran a lot of server machines distributed over many sites including network centersw and kernel level smoke & mirrors undermines the whole point of switching to the fd based call. Developers have a tendency to pick the easy option and if you're worried about exploits to race conditions, giving them shell access gets your hosts remotely cracked.