Sad outcome

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

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.