DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43652>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43652 Summary: Suggest small change for big fix with SuExec & Virtual Hosts Product: Apache httpd-2 Version: 2.2.4 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: mod_suexec AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Whether this is a "bug" or not depends on your point-of-view regarding suexec and common hosting configurations. I commonly setup virtual hosts by creating a user account, then a 'public_html' directory in that user's home directory, and then finally mapping the Virtual Host document directory to that user's public_html directory. It makes everything nice and neat and simple for everybody-- everybody that is except people needing suexec. I'm not putting home directories in the apache document root, it ain't gonna happen. Likewise, I'm not making the apache document root to be the base of the home directories. That's not going to happen either. Most users don't know about (and don't want to know about) the "~user" syntax, so effectively that's a non-starter as well. So if you're using suexec out of the box, you're pretty well hosed-up at this point. I've been studying the suexec.c utility and it seems pretty tight the way it is. I could hack it up but it seems a shame to have to resort to that. On the other hand, my opinion is that its become so locked-down (and for good reason) that people DO look for ways around it, or else to modify it, to support this one very common hosting configuration. Or else look for ways to "cheat" using suid programs and the like to dart in, create a file the user can use-- or some other trick, which likewise causes a number of security risks. So while its possible to modify suexec.c to shoe-horn in support for the userdir/public_html virtual host configuration, it doesn't seem to be the best solution available. However, in looking over the code, it seems that the "target_username" and "target_groupname" are GIVEN to suexec by apache (via mod_suexec) along with the target command. It goes through its various checks to determine whether or not blah blah blah is valid etc etc etc and finally deciding to accept or not accept the user/group/command combination. Of course in the case of the configuration I'm describing, it will always be "not accept" -- bummer! So here's the little change I was thinking of--- as I was musing over the best way to hack and slash suexec.c to shoe-horn in what I needed, it occurred to me (and I think this is true-- someone say otherwise if I'm wrong)-- that the only place the "SuexecUserGroup" construct (in the VirtualHost config) comes into play is when its given to the suexec program as a target username and groupname. However, it turns out that this bit is parsed by the apache program itself and it doesn't like it if its not a real "legitimate" user. But if (!!!) it were possible to persuade apache to not care so much if you specified "~username" and "~groupname" then THOSE names would get passed to the suexec program which (I *think*) would then treat them as the regular "~user" form that it already knows about and is willing to accept. IF apache needs the username/groupname for something else-- just let it notice the leading tildes and ignore them. But if its going to hand them to suexec, include them. Then I think everything works out for everybody and suexec does NOT need to be changed AND people who want to setup their virtual hosting in the manner I've described can do so, AND only a very tiny tweak to Apache (config-handling) is required to effect the change. Opinions??? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
