<div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 27, 2017 at 11:54 PM, Darren Moffat <span><<a href="mailto:darren@nessieroo.com" target="_blank">darren@nessieroo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Is the use case for when we are purposely creating a multi-process system, by using fork/vfork/clone, </div></blockquote><div> </div></div></div></div></div><div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><div>Fork also duplicates a number of things not just data (copy on write)<br></div><div>but also file descriptors, UID, GUD, effective  UID and GID, atributes for SeLinux and more state.  </div><div dir="auto">A privileged process needs to reliably shed some data and privledge to not leak information. </div><div dir="auto"><br>A single binary can contain code to do a multitude of things. Some  that should not happen in the same binary or process. </div><div>A named pipe or shared memory buffer could be used by a generator in a forked-child to feed </div><div>data to the parent or yet another process.  I.e. a child might interact with dev/random and a PRNG but keep the random seed hidden from the parent.   Each child would wake to find a clean slate</div><div>and not see any 'secrets' that were marked to be wiped but could cooperate in a multi process problem. </div><div dir="auto"><br>Example to ponder:  BusyBox: The Swiss Army Knife of Embedded Linux does a lot of stuff</div><div>in one binary and one acts like a shell.   Any of its child processes could be a fork()</div><div>or fork(); exec() pair of itself with another entry point. Commonly built and fully linked to not depend on shared objects there are lots of eggs (tools) in one basket.</div><div dir="auto"><br></div><div dir="auto">Wipe on fork seems necessary but may not solve all problems.  In crypto a Swiss Army knife binary an advantage could be a single file atomic update that is “easy to update” but would contain tools to operate, on keys, input, output, generate keys, etc...  perhaps too many things. </div><div dir="auto"><br></div><div dir="auto">SSD files that are ephemeral could be unlinked and encrypted with a one time dev/random pad generated and optionally expanded perhaps with a PRNG so any part of the pad can be regenerated using a use once true random seed set and XOR to obscure bits on SSD components or even hidden blocks on spinning rust should there be a power interruption or core dump. </div><div dir="auto"><br></div><div dir="auto">Persistent data and encryption is a hard, key management problem especially in a multiuser system.</div></div></div></div><div><div><div class="gmail_extra"><div><br></div>-- <br><div class="m_1352826366580992441gmail_signature"><div>  T o m    M i t c h e l l</div></div>
</div></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Tinny keyboard.. Mobile ... I am</div>