title: Is there any security benefit gained by fork()ing after dropping (root) privileges?
body: <p>Especially in the Linux/POSIX world, daemons that need some root capabilities for temporary initialization purposes only (e.g., to read a root-owned private key file, or to open a port&lt;1024, or to increase resource limits), often seem to follow a design pattern where they change their credentials with function calls such as <code>setuid()</code>/<code>setresuid()</code> and <code>setgid()</code>/<code>setresgid()</code>, and then call <code>fork()</code> to run the actual program as its child. Supposedly the <code>fork()</code>-ing is done <em>"just in case"</em>, but what is or was the actual security consideration for doing so?</p>
  
  <p>And to follow up on that, is that reason still relevant when (in addition to <code>setgroups(0, NULL)</code>, <code>setresgid(GID_NOBODY, GID_NOBODY, GID_NOBODY)</code> and <code>setresuid(UID_NOBODY, UID_NOBODY, UID_NOBODY)</code>), the program is also proactively limiting <em>Linux capabilities</em>, by dropping every capability as soon as it is no longer needed, by calling <code>cap_set_proc()</code>?</p>