When executing CGI's inside a Userdir, Apache attempts to run the CGI at the SuexecUserGroup from the VirtualHost directive instead of the user who's directory we're looking at. This trips the security protection in suexec and causes an Internal Server Error message. Suexec logs something like: [2003-03-19 18:57:32]: target uid/gid (1000/1000) mismatch with directory (1053/1053) or program (1053/1053) (Where 1000/1000 is the SuexecUserGroup for the 'ares.penguinhosting.net' named virtual host, and 1053/1053 is the user/group of 'david' for the listed URL). Apache 1 behaves properly in the same case.
I'm having the exact same problem. Running suexec in the document root is no problem, however, Apache is not sending the "~" to Suexec when a userdir is accessed.
Are you actually using mod_userdir ONLY to serve these requests, or is there some kind of Alias/ScriptAlias/RewriteRule that is involved?
I've got some Rewriterules, but they don't apply for the UserDir directive. This is my VirtualHost config: <VirtualHost www.domain.nl:80> SuexecUserGroup username group ServerAdmin emailaddress DocumentRoot "/home/sites/site1/web/" <Directory "/home/sites/site1/web"> Options Indexes FollowSymLinks MultiViews Includes +ExecCGI AllowOverride All Order allow,deny Allow from all </Directory> ServerName www.domain.nl ServerAlias *.domain.nl domain.nl RewriteEngine On RewriteRule ^/personal/?$ http://www.domain.nl:81 [L,R] RewriteRule ^/siteadmin/?$ http://www.domain.nl:81 [L,R] RewriteRule ^/admin/?$ http://www.domain.nl:81 [L,R] RewriteRule ^/login/?$ http://www.domain.nl:81 [L,R] RewriteRule ^/webmail/?$ http://www.domain.nl:81/webmail/ [L,R] RewriteRule ^/fileman/?$ http://www.domain.nl:81/webmail/ [L,R] RewriteOptions inherit <Directory "/home/sites/site1/users/*/web"> Options Indexes FollowSymLinks MultiViews Includes +ExecCGI AllowOverride All Order allow,deny Allow from all </Directory> ErrorLog /home/sites/site1/logs/error.log CustomLog /home/sites/site1/logs/web.log combined </VirtualHost> In httpd.conf the following is set: UserDir web and my suexec -V output is: -D AP_DOC_ROOT="/home/sites/" -D AP_GID_MIN=100 -D AP_HTTPD_USER="www" -D AP_LOG_EXEC="/usr/local/apache2/logs/suexec_log" -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin" -D AP_SUEXEC_UMASK=022 -D AP_UID_MIN=100 -D AP_USERDIR_SUFFIX="web"
Anything new regarding this bug? I'm facing EXACTLY the same problem on 2.0.49, which renders it completely unusable for me. Apache 1 worked fine, it used User and Group when no UserDir request was made, and used the correct user when a UserDir request was made. Please have a look at this soon, it prevents me from using 2.x :-(
Attached is some system information that might be helpful. My configure command-line: ./configure --enable-mods-shared=all --enable-ssl --enable-proxy --enable-suexec --with-suexec-caller=nobody --with-suexec-docroot=/home Output of suexec -V: -D AP_DOC_ROOT="/home" -D AP_GID_MIN=100 -D AP_HTTPD_USER="nobody" -D AP_LOG_EXEC="/usr/local/apache2/logs/suexec_log" -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin" -D AP_UID_MIN=100 -D AP_USERDIR_SUFFIX="public_html" Output of apachectl -V: Server version: Apache/2.0.49 Server built: Apr 10 2004 13:17:23 Server's Module Magic Number: 20020903:7 Architecture: 32-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" Relevant settings in httpd.conf: UserDir disabled UserDir disabled root [...] <Directory /home/*/public_html> AllowOverride All Options -Indexes MultiViews ExecCGI SymLinksIfOwnerMatch IncludesNoExec Order allow,deny Allow from all </Directory> [...] <Directory /home/sites/*/users/*/public_html> AllowOverride All Options -Indexes MultiViews ExecCGI SymLinksIfOwnerMatch IncludesNoExec Order Deny,Allow Allow from all </Directory> Relevant settings in my included virtualhosts.conf: NameVirtualHost *:80 <VirtualHost *:80> ServerName my.main.domain UserDir disabled UserDir disabled root RewriteEngine on RewriteOptions inherit </VirtualHost> [...] <VirtualHost *:80> ServerName www.sub.domain.ofmine ServerAlias sub.domain.of.mine ServerAdmin my@root.address DocumentRoot /home/sites/s1234/users/u0001/public_html UserDir disabled UserDir disabled root UserDir enabled s1234u0003 [...some other enabled UserDirs...] SuexecUserGroup s1234u0074 s1234 RewriteEngine on RewriteOptions inherit [...some RewriteRules...] </VirtualHost>
Anything new in here? This one is a really bad one :-(
Perhaps someone could answer to the question regarding the scriptalias directives? Or better - attach the *full* config?
I have attached my config. Is there some important part missing? It doesn't work with and without RewriteRules.
'm guessing this is a variation of the 'bug' (really documentation problem) with suexec + UserDir in Apache 2.0.x. Basically, you cannot use the 'old style' scriptalias directives with user dirs and suexec. Try this version of your user CGI bin directory setup: <Directory ~ "/home/sites/site1/users/*/web"> Options Indexes FollowSymLinks MultiViews Includes +ExecCGI AllowOverride All Order allow,deny Allow from all SetHandler cgi-script </Directory> Oh, you need to include the UserDir and SuExec modulea: LoadModule userdir_module modules/mod_userdir.so LoadModule suexec_module modules/mod_suexec.so And *don't* include any sort of scriptalias for your user's dirs.
LoadModule suexec_module modules/mod_suexec.so and LoadModule userdir_module modules/mod_userdir.so are activated in my httpd.conf. However, your solution shown below does not help. :-( May I e-mail you my httpd.conf and my included virtualhosts.conf, so you can check it? Because of data privacy and security issues, I don't want to attach the full configuration to this bug. May I e-mail it to you privately? Thanks!
I'm not one of the Apache developers, just a fellow user of suexec. I am not sure how much help I can give you. I don't presently have an Apache 2.0.x server installed and running anywhere at present, so I cannot actually test anything either. All I know is that It is entirely possible that it is a real bug. Maybe what you need to post is a stripped down version of your httpd.conf and virtualhosts.conf files, ones that are minimually suffientent to cause the problem, but which don't leak any real (priviledged) data -- this way the developers can re-create your problem and then come up with a working solution.
Hi there, and thanks for the quick reply ;-) If any of the developers could post to this bug (I haven't heard anything from them yet ;-( I'd happily provide them with my httpd.conf ;)
Here's what you should do: Start with a default install of apache from httpd.apache.org, and then make the absolute minimum changes that are necessary to show the problem. Then give us a list of the changes.
Here it comes ;-) System installed on: Debian GNU/Linux Sarge x86 Non-FQDN hostname of the system tested on: floeff3.effenberger (sometimes mentioned in the configuration file) Apache source code used: http://www.artfiles.org/apache.org/httpd/httpd-2.0.49.tar.gz Steps taken for compilation: - apt-get install libssl-dev binfmt-support - ./configure --enable-mods-shared=all --enable-ssl --enable-proxy --enable-suexec --with-suexec-caller=nobody --with-suexec-docroot=/home - make - make install - addgroup site1 - adduser --shell /bin/false --ingroup site1 user1 - mkdir /home/user1/public_html - chown user1:site1 /home/user1/public_html - adduser --shell /bin/false --ingroup site1 user2 - mkdir /home/user2/public_html - chown user2:site1 /home/user2/public_html - Content of /home/user1/public_html/whoami.pl and /home/user2/public_html/whoami.pl: #!/usr/bin/perl print "Content-type: text/plain\n\n"; system "whoami"; - chown user1:site1 /home/user1/public_html/whoami.pl - chmod 755 /home/user1/public_html/whoami.pl - chown user2:site1 /home/user2/public_html/whoami.pl - chmod 755 /home/user2/public_html/whoami.pl Open http://floeff3 => "user1" is being printed Open http://floeff3/~user2/ => Internal Server Error with [2004-04-29 16:01:36]: target uid/gid (1002/1004) mismatch with directory (1003/1004) or program (1003/1004) # id user1 uid=1002(user1) gid=1004(site1) groups=1004(site1) # id user2 uid=1003(user2) gid=1004(site1) groups=1004(site1) I have put the configuration changes I've made together in the attached patch file which you should use against /usr/local/apache2/httpd.conf Please let me know if you need anything else. Thanks for taking the time. ;-)
Created attachment 11376 [details] patch for the original httpd.conf file
Thanks, that's clearer. But there is still some stuff which I assume is irrelevant to your problem, like the mod_rewrite directives and the UserDir disabled stuff. Does your problem go away if you remove those? Unfortunately, I don't have a unix system available to test on at the moment. I've looked at the code, and it appears to me that when both SuexecUserGroup and mod_userdir is active, there is no defined ordering between the get_suexec_identity hooks. So perhaps the userdir suexec stuff doesn't work at all if SuexecUserGroup is present. In that case, simply fixing the hook ordering could fix the problem.
Thanks for your fast reply! I've set the following lines (in the patch) to the httpd.conf defaults: === -UserDir public_html +#UserDir public_html +UserDir disabled +UserDir disabled root [...] +RewriteEngine on +RewriteOptions inherit [...] +Userdir enabled user2 === I still get an Internal Server Error, so they don't seem to have anything to do with the problem. ;-) Is there anything else you need or did I sent all information necessary to fix the bug?
Here's a wild guess: Index: mod_userdir.c =================================================================== RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_userdir.c,v retrieving revision 1.52.2.4 diff -u -d -b -r1.52.2.4 mod_userdir.c --- mod_userdir.c 9 Feb 2004 20:53:19 -0000 1.52.2.4 +++ mod_userdir.c 29 Apr 2004 15:38:30 -0000 @@ -350,7 +350,7 @@ ap_hook_translate_name(translate_userdir,aszPre,aszSucc,APR_HOOK_MIDDLE); #ifdef HAVE_UNIX_SUEXEC - ap_hook_get_suexec_identity(get_suexec_id_doer,NULL,NULL,APR_HOOK_MIDDLE); + ap_hook_get_suexec_identity(get_suexec_id_doer,NULL,NULL,APR_HOOK_FIRST); #endif } If that isn't it, you'll have to wait for another developer to look at it, since I don't have the resources to do suexec testing.
Thanks Joshua, this one seems to work! I've tested it locally, and I have no problems anymore! ;-) Will this bugfix be incorporated in 2.0.50?
I won't commit this myself, since I can't test it. But another developer will hopefully pick it up. This could be considered a non-compatible change, since there is a chance someone might be relying on SuexecUserGroup taking precedence of UserDir for suexec. But this change should get us closer to the way it worked in 1.3, and it makes sense to me as the expected way things should work, so I think it should be committed.
Okay :) Maybe you just have to make the change clear in the change log or add an option for httpd.conf to choose between the "new old" and the 2.0 default behaviour. Thanks again for your quick reply and great help, much appreciated!
Where can I "find" a developer to test and eventually contribute this to the CVS? :-)
A workaround is to swap the order of the LoadModule lines for suexec and userdir. I'll test Joshua's patch: it's hard to argue this is an incompatible change since the current behaviour is not defined so it's OK for 2.0 as well, I'd guess.
Committed, will propose for backport. Thanks for the report and thank you Joshua for the patch.
Thanks a lot for implementing it! :-)