Bug 43652 - Suggest small change for big fix with SuExec & Virtual Hosts
Summary: Suggest small change for big fix with SuExec & Virtual Hosts
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_suexec (show other bugs)
Version: 2.2.4
Hardware: All Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2007-10-18 09:10 UTC by JWHITTEN
Modified: 2018-11-07 21:10 UTC (History)
0 users

Patch to make suexec work with virtual hosts stored in users personal web directory (1.89 KB, text/plain)
2008-09-26 23:44 UTC, Alain Knaff

Note You need to log in before you can comment on or make changes to this bug.
Description JWHITTEN 2007-10-18 09:10:08 UTC
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.

Comment 1 JWHITTEN 2007-10-18 11:02:10 UTC
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... 
Comment 2 JWHITTEN 2007-10-18 11:06:05 UTC
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.
Comment 3 Alain Knaff 2008-09-26 23:44:29 UTC
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.


<VirtualHost *:80>
        ServerName alain.hitchhiker.org.lu
        SuexecUserdir alain alain
        DocumentRoot /home/alain/public_html
Comment 4 William A. Rowe Jr. 2018-11-07 21:10:01 UTC
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.