[Let's continue the discussion privately from now on as it's becoming less relevant for the httpd project...]
On 2/2/07, Arnold Daniels <[EMAIL PROTECTED]> wrote:
... >> You do not need a secret, but the users who may changed are specified. >> In our setup user 'www-data', which has no privileges on the server, may >> change into any shared hosting user. Within the process where www-data >> changed into the shared hosting user, a call can be made to change back >> into 'www-data'. Since running a CGI script starts a new process, it is >> not possible for a shared hosting user to change into 'www-data' using a >> custom CGI script. > > Good. Still, if you allow PHP users to load their own code from shared > libraries they'll be able to revert back to the www-data user. > Due to permissions it isn't possible for customers to place any files in the extension directory and PHP won't load any binaries outside that directory. Anyhow it is highly recommended that dl() is disabled. Which is the case on our system.
Good. Still, you are relying on mod_php to enforce certain restrictions. I prefer a mechanism where you can deploy securely with any module and any module configuration.
>> We don't log to file, but use UDP, still the same goes. A hacker can't >> really accomplish anything with writing data to the log, except maybe a >> bit of vandalism. > > I actually think that is a very serious problem. With the ability to > add to the access logs someone could frame a person for hacking. > I'm not sure how the privileges of the access log are currently set on our system. But the access log could of course be written by www-data, so before the user is switched, which solves the problem.
If you are using syslog/UDP then, because syslog lacks authentication, any user can fake an access log entry. As for the access log permissions - root should be the only user allowed write access. Either way, if a file descriptor is inherited then any user can write to it (permissions of the user that opened the FD are used). -- Ivan Ristic
