[In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Synopsis: questionable user promotion State-Changed-From-To: feedback-closed State-Changed-By: brian State-Changed-When: Wed May 20 19:33:25 PDT 1998 State-Changed-Why: >(a) in util_script.c, it is possible to execute through an exec with >SHELL_PATH instead of SUEXEC_BIN, shell path does not run with the >protection of suexec (obviously.) This allows users to try >'nasty' things under the cloak of the webserver user. Only if they can put things in the directories where that is the case. For example, an ISP might only ever allow CGI scripts in home/public_html directories, and keep the "normal" documentroot area available only to one or two people they trust (or no one). Obviously the non-home-dir scripts will run as the server's userid, usually "nobody", and any well- designed system will have restrictions on what the "nobody" user is. The only way to get higher security than this is to use the chroot jail modules which are available out there; we didn't pursue that route because we wanted a little more flexibility. >It also is >inconsistent, I may have a CGI in one location to save private >data, but then my SSI cannot retrieve this private data. Sure it can, with <!--#include virtual="" -->. >If the file resides within the web server's domain, then it should >execute it as the owner of the (realpath of the) file. The checks have to be more rigorous than that, or it becomes too easy to "steal" privileges. Consider an equivalent situation in SMTP-land, where qmail won't deliver to a .qmail (its version of .forward) if the file is group- or other-writeable, or if the directory it's in is group- or other-writeable. >My personal touch also is that if it is not inside the web >server's domain it should have sticky bits set (ie >indicating that changing ownership isn't a problem anyway.) But then any Joe Random User on the site can run this CGI script, without any of the extra protections that suexec provides. >The theory is, why would someone else's file be in my >directory? Because a user might be clueless about file permissions and "I just wanna run my guestbook script", etc? Especially since so many CGI packages out there advocate setting things chmod 777 - makes me want to scream. >my document root is : "/var/httpd/htdocs", so that my users do not >have to place a tilde (~) in their URL's, I do : >"ln -s ~username/public_html /var/httpd/htdocs/username" >The web server gets confused as it does not realize that >the real location is /home/username/public_html... I >believe it now backtracks realpath's to verify for >.htaccess, but I do not believe it backtracks >to find out the true owner of the directory. You can use mod_userdir in ways which allow you to not have to use "~", yet still allow suexec to work properly. >I realize I am using the web server differently than >expected, but nonetheless, the user and group id's >should be determined through the realpath of the file, >not the sympath of the file. Yes, but there will be other times when people ask for the opposite (for example, access controls), so we should choose one path and stick with it, and we have. >Anyway, I hope you see it from my point of view. My real >problem is that if you set suexec then everything should >run with suexec. I think reasonable people can clearly disagree on this; the beauty of Apache is that you can configure things, without any source code modifications, to accomplish exactly what you have stated you want to accomplish. Thanks.
