Re: [TUHS] Systematic approach to command-line interfaces

["Theodore Ts'o" <tytso@mit.edu>]

On Sun, Aug 01, 2021 at 06:13:18PM -0600, Andrew Warkentin wrote:
> There's a third kind of primitive that is superior to either spawn()
> or fork() IMO, specifically one that creates a completely empty child
> process and returns a context that lets the parent set up the child's
> state using normal APIs.

I've seen this argument a number of times, but what's never been clear
to me is what *would* the "normal APIs" be which would allow a parent
to set up the child's state?  How would that be accomplished?  Lots of
new system calls?  Magic files in /proc/<pid>/XXX which get
manipulated somehow?  (How, exactly, does one affect the child's
memory map via magic read/write calls to /proc/<pid>/XXX....  How
about environment variables, etc.)

And what are the access rights by which a process gets to reach out
and touch another process's environment?  Is it only allowed only for
child processes?  And is it only allowed before the child starts
running?  What if the child process is going to be running a setuid or
setgid executable?

The phrase "all process state will have a file-based interface" sounds
good on paper, but I think it remains to be seen how well a "echo XXX
> /proc/<pid>/magic-file" API would actually work.  The devil is
really in the details....

					- Ted