Quoting Darren Kenny <Darren.Kenny@ireland.sun.com>: > The 'NORM' in situations like this is that the application (in this case > httpd) is run initially as root - which is usually the case to bind to > port 80 - and then it setuid's to the user nobody. The main thing is that > the httpd process has root privileges still, it can temporarily setuid to > root to do things that require root privileges (such as authentication) and > then drop back down to the lower privilege for everything else... That's > usually how this is handled as it should be possible for any PAM library to > be able to assume it's root when it's doing privileged operations like > authentication. God, no. The *only* reason httpd needs root *at all* is in order to bind to a low port. After it's done what it needs to do, it should drop privileges *without* the possibility of resuming them. This is pragmatism in programming: the less code that runs with privileges, the less code you have to audit for certain types of problems and the more likely that it /will/ be correctly audited. I don't want my entire webserver (and countless customer scripts) running as root, or even with the possibility of gaining root through less than extraordinary means. Fortunately Apache does as I've described, and I don't have to worry about some PHP script cracking root -- even though this means jumping through some more hoops to get PAM working. As far as PAM being able to assume it's running as root, I don't think that's a necessary precondition; there are many useful types of authentication that don't require root privileges. I still say it would be nice, however, if PAM modules could assume the calling program was running with *maximum possible* privileges... the setuid logic in pam_unix, for example, would be much simpler if this were the case. Steve Langasek postmodern programmer
