This article is nonsense. I'm afraid.<p>Firstly, the su program isn't standardized by POSIX, so everything we say about it is system-dependent.<p>On the systems where that trick is used, su is documented as having that feature.<p>When su is executed by root (so that its setuid bit is moot), it knows this, and allows a credentials change to a specified account without prompting for a password. This is a feature and the example cron jobs are using it correctly to obtain their desired effect of impersonating that user.<p>su is not "dropping privileges"; it's impersonating a specific user, in a command dispatched from a root cron job or other script.<p>Thus all that might be wrong is the <i>rhetoric</i> used to describe the scripts, not what the scripts are actually doing, and only if we are nitpicky.<p>"Dropping privileges" has a strict meaning, referring to the situation that some user <i>bob</i> invoked a setuid root executable, which then disrobes itself of the root privilege, changing its effective-root uid to just <i>bob</i> again.<p>When root changes to another account that is unrelated to the real user ID, nevertheless, that situation fits the description of "dropping privileges" because that account is strictly less privileged than root.<p>> The right way ... Create a small wrapper binary with C<p>That's a silly nonstarter.<p>> <i>The new implementation called fork() and only dropped privileges in the child, retaining a privileged account parent process that could call the PAM "user session" cleanup function once the child exited.</i><p>Privileged parents waiting for unprivileged children to terminate is an established pattern in Unix-like systems.<p>E.g. PID 1 (init or systemd) is privileged and handles the termination of everything that has no parent.<p>The author is not connecting the dots here: reporting some actual privilege escalation bug in the use of "su bob command ...".<p>Interactively, when you are root, you can do this:<p><pre><code> root # su bob
/home/bob$ exit
root #
</code></pre>
This exit back to root is not a security hole, and it is not relevant to the scripted scenario at all. Bob has not actually gained root access. The order of messages on the TTY isn't what determines the security context semantics.