Joshua Slive wrote: > > > From: Aaron Bannert [mailto:[EMAIL PROTECTED]] > > > > These things can not be passed on the command line. That is a gaping > > > security hole. suexec is designed in a very restrictive manner > > on purpose > > > with the assumption that anything passed on the command line is suspect, > > > and should be treated as such. That is why there is a hardcoded > > > docroot, etc. > > > > > > > Hmm...This was my main concern. Is there any way we can make suexec's > > docroot relative to the ServerRoot (determined at runtime)? Although > > suexec itself protects against it, we probably want to either come up with > > a way to support relative paths, or write autoconf code to fail/disable > > suexec when relatives paths are specified. > > It is crucial that this is not run-time configurable. When the admin gives > suexec suid permissions, he needs to know exactly what he allowing. Any > run-time configurability breaks that, which is what Marc is pointing out. > Think of what happens if a malicious user should compromise the apache > userid. Then we need to make sure that he cannot reconfigure suexec in any > way. The only way to do this is to lock everything at compile time. > > The things that I can think of to make suexec easier to use: > > 1. Improve the compile-time configuration. > > 2. Rename "suexec docroot" to something that will not be confused with > "DocumentRoot" in apache. > > 3. Have suexec write a stderr message into the apache error log when it > fails. I'm not sure if this one is possible in the security model. >
Another option is to make suexec "post compile-time, pre run-time configurable" by using an suexec config file. The path would need to set at compile-time and absolute, and paranoid permission checking would need to be performed on the file and all parent directories. rsbx
