Drew DeVault is a user on cmpwn.com. You can follow them or interact with them if you have an account anywhere in the fediverse.

@sir IMO
1. exec would be useful even without fork
2. CLOEXEC is not a hack, at least not more than inheritable capability set.
3. memory overcommitment is a feature, would exist even without fork, and can be disabled with a sysctl knob
4. AFAIK the NT kernel has neither rfork/clone nor exec, which IMO sucks.

You can implement spawn with clone+exec, but can't implement exec with clone+spawn, or clone with spawn+exec. So you need clone and exec anyway.Spawn is at most a special case optimisation

@Wolf480pl
>exec would be useful even without fork
Agree
>CLOEXEC is not a hack, at least not more than inheritable capability set.
CLOEXEC predates rfork-like approaches, it's totally a hack
> memory overcommitment is a feature, would exist even without fork, and can be disabled with a sysctl knob
I know, this doesn't change my arguments much. Fork was the impetus for overcommittment, and more rationale was added later iiuc
>You can implement spawn with clone+exec
Poorly, maybe

@sir
IMO even if you have rfork or spawn, you still want to sometimes exec (and not spawn) an untrusted binary that shouldn't have access to some of your FDs.

As for memory overcommitment, I bet someone would invent it sooner or later, but maybe the default setting would be different.

As for implementing spawn with clone+exec, it'd be inefficient, yes, but would eventually lead to the same state.

@Wolf480pl I already agreed that exec is a good thing, and even said so in the article

@Wolf480pl oh, I see what you mean. I hinted at this in the article but in my ideal world we use something somewhere in the middle between rfork and spawn, where you can choose to spawn a process into your address space and with some of your resources.

@sir I believe you can do that with clone(), but it won't be the same PID.