1. 7

  2. 3

    The post says that su forks a child process to actually run the command so that the parent process can still run as the original user. But I didn’t follow what problem that causes.

    If the forked process runs as the target user then you have successfully dropped privileges right?

    1. 1

      If I understand correctly, I think it’s specifically a problem for “managed” daemon type processes: the parent (which still has elevated permissions) is the process that the manager knows about, so must stick around to continue to respond to signals from the management layer. If the parent could fork and terminate it would be fine, and that may be safe if you don’t have any other processes communicating with the parent pid (though I’m unsure of the implications of tearing down the parent’s PAM session while the child is running… it seems like that should be ok, but not familiar enough with PAM to be sure of that.)

      1. 2

        I am still not sure I understand. If you’re doing this old school, the child process will drop the PID file and no one cares about the su process. If it’s a modern supervisor then it will manage process trees and, when su exits, will adopt its children. That’s certainly what happens on FreeBSD with anything that uses the reaper APIs and, I believe, with the Linux equivalents.