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???
The thing that would blow this nifty idea is if Apache hands suexec the server name rather than the username from the config file. And in retrospect (things are always clearer then aren't they?) my guess is this is what happens otherwise there would be no need to deal with the tilde at all...
Perhaps the servername to username translation could happen in the mod_suexec module and the it would work as originally posited? The one caveat, and I don't think its a big one (my opinion) is that if this idea works, it would imply that each virtual host had to be tied to one and only one user in order to use suexec. You could't have 10 virtual hosts all using the same username/groupname combination since it would have to resolve in the end to one user's public_html directory. But I don't think that's a major limitation, and indeed I think that is the way that most people using this type of configuration actually do it-- I know that's the way I've always done it. And anywhere else I've had an account/virtual host set up has done it.
Created attachment 22641 [details] Patch to make suexec work with virtual hosts stored in users personal web directory The attached patch (against version 2.2.9) adds a new configuration option "SuexecUserdir" that invokes suexec with the tilde, so that it works in user's homedirectories. The old "SuexecUserGroup" continues to operate as before, so that it works in the global documentroot. Example: <VirtualHost *:80> ServerName alain.hitchhiker.org.lu SuexecUserdir alain alain DocumentRoot /home/alain/public_html </VirtualHost>
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.