Joshua Slive wrote:
This has not changed between 1.3 and 2.0. suexec always requires all non-userdir files to be under a compile-time configured document root. It must just be that the docrot you had configured for 1.3 contained all the directories. You can recompile suexec to set its docroot to /home. But of course, this is dangerous because it means suexec can execute anything under that directory.
Thanks for the info. In the past, I must have recompiled suexec with a docroot of /home. :( Ok -- a quick check of my old binary from a backup confirms that. So -- there really isn't a way to make this work as I'd like in a more proper way then, is there?
However, suexec still checks that the file is owned by the user trying to run it, correct? Therefore, is doing a document root of /home (or even / and ignoring the doc root check for that matter) that insecure/dangerous if it only allows people to run things that they already own? I realize it isn't perfect -- but it seems it would solve my problem and not be a large risk to allow users to execute files that they own. Since they could execute whatever was in /var/www/* if it was done the "proper" way, am I changing things much to allow them to execute a file they own anywhere else on the filesystem? Or am I missing something obvious?
All that being said, what do other people do that do virtual hosting for clients? Do they keep individual client directories under /var/www/ then? And, if so, how do they give FTP access to those files? Just chroot them to that directory all the time instead of their home directory? Or maybe MAKE that their home directory? We have people that have web space and other files in their home directories -- which is why I was trying to do it my way -- so that I could keep them jailed to their home directories for FTP...
Thanks again. - John... --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|