On Sun, Dec 27, 2020, at 14:53, Gregory P. Smith wrote:
> Most prctl uses I noticed were PDEATHSIG but I'd need to explicitly 
> audit those.  Users don't seem to care about it's documented main 
> thread caveat (which matches what I've seen; most programs don't use 
> non-daemon threads and exit the main thread).

It works great until someone refactors their process-launching code to be asynchronous. Anyway, I don't mean to bog this discussion down in the advisability and utility of PDEATHSIG. Clearly, it needs to be supported to remove even less advisable functionality.

> 
> I want what we do for this to be futureproof for the syscall so that we 
> don't wind up merely picking one feature such as PDEATHSIG to pass a 
> flags through to and needing to add logic to support others later on, 
> delaying the ability to use new system features.

The proposal right now feels like overgeneralization leading to an icky interface. It seems in spirit no different form providing a similar interface to syscall(3). At some point the interface will become so general it defeats the initial purpose of introduction, to disallow arbitrary code execution before execve. There will always be new syscalls, multiplexed into prctl/ioctl or not, that people want to make before execution. The universal workaround of a wrapper program can satisfy those on the vanguard.