(I have apache 2.0.51 but can't select it from the version list) I have the following problem: There's some virtualhost with suexec enabled and vh directory with includes enabled. I've created test.shtml page and trying to execute cgi command from it: <!--#exec cmd="sample.cgi" --> this one works ok suexec log output: uid: (1000/divisor) gid: (45000/45000) cmd: sample.cgi then I move sample.cgi to the some dir i.e. called '5' and change test.shtml content to <!--#exec cmd="./5/sample.cgi" --> this one stops working suexec log output: uid: (1000/divisor) gid: (45000/45000) cmd: sample.cgi [2004-09-20 00:18:00]: cannot stat program: (sample.cgi) but works fine if disable suexec in the virtualhost config. virtualhost config example: <VirtualHost 172.16.1.1:80> ServerAdmin webmaster@domain.com DocumentRoot /home/divisor/domain.com ServerName domain.com SuexecUserGroup divisor divisor <DIRECTORY //home/divisor/domain.com> OPTIONS Indexes FollowSymLinks Includes AllowOverride All </DIRECTORY> IndexOptions FancyIndexing </VirtualHost>
In 1.3.x suexec executes programs in subdirs well if there's a correct relative path in the ssi command. I noticed that apache 2.0.51 gives to suexec just a program name, without a path, i.e. example.cgi instead of ./somedir/example.cgi when 1.3.x gives to suexec a program name together with a path. Maybe this is a feature of 2.0.x :) but many sites have such includes and can't be transferred to 2.0.x if the system is configured to work with suexec. If the problem executing programs in subdirs via ssi+suexec isn't going to be solved in 2.0.x could you plz advice how to configure or manually patch apache 2.0.x to transfer such sites? I would be greatly appreciated. Thanks you.
I've figured this out writting such patch: -- FILE START -- --- os/unix/unixd.c.orig Mon Sep 20 04:09:08 2004 +++ os/unix/unixd.c Mon Sep 20 04:09:27 2004 @@ -308,15 +308,7 @@ return apr_proc_create(newproc, progname, args, env, attr, p); } - argv0 = ap_strrchr_c(progname, '/'); - /* Allow suexec's "/" check to succeed */ - if (argv0 != NULL) { - argv0++; - } - else { - argv0 = progname; - } - + argv0 = progname; if (ugid->userdir) { execuser = apr_psprintf(p, "~%ld", (long) ugid->uid); -- FILE END -- what was that check for? security feature to avoid running external programs? If so they can be executed anyway under the same permissions directly from the program executed from the current dir. I guess it was unusual. Please comment. Thanks.
WORKSFORME is used to indicate that the problem can't be replicated with the current source code. I don't think that is what you intended.
Same problem here, still present in 2.0.53. Michael's suggested fix effectively reverses the changes to os/unix/unixd.c added by Ryan Bloom on 2002-06-26 (for 2.0.40), see http://mail-archives.apache.org/eyebrowse/ReadMsg? listName=cvs@httpd.apache.org&msgNo=21396 "Fix a long-standing bug in 2.0, CGI scripts were being called with relative paths instead of absolute paths. Apache 1.3 used absolute paths for everything except for SuExec, this brings back that standard." I'm not completely sure about possible side effects of reversing the changes to unixd.c, so would appreciate if a current Apache HTTP server project member could have a look at this issue (Ryan is now listed as an emeritus member). BTW, #29534 seems to be a duplicate of this bug (or the other way round, since 29534 was actually filed earlier). Thanks, Kaspar
My personal opinion, without any carful study is that this is the wrong fix. The original patch was put in for valid reasons and should stay. However, mod_include needs a patch that turns CGI script paths into absolute paths. That will keep everything working.
Created attachment 14563 [details] proposed fix
Well, nobody seems to have picked up so far, so here's my try. > mod_include needs a patch that turns CGI script paths into absolute paths. That's what my proposed fix tries to do. The code handling the SSI exec tag has actually been moved to mod_cgi (before 2.0.10 already), so that's where the patch goes. In handle_exec(), I have added a check to make sure an absolute pathname is used when calling include_cmd()/run_cgi_child(). For suexec, the important point is that in run_cgi_child() the directory for the new child is set to the parent of "command", not the one of r->filename (they differ if the "exec" target is not in the same directory as the shtml file). I've tested this both with relative and absolute file names for the "cmd" parameter, and running with and without suexec. It works for me (as predicted by Ryan), but further testing is welcome, of course. And finally, I'd appreciate to see this fix (or a similar one) in 2.0.54... thanks!
*** Bug 29534 has been marked as a duplicate of this bug. ***
PatchAvailable keyword added
I can still confirm this issue for 2.0.55. I think it's getting time to bring this fix to HEAD.
The version 2.0.63 of apache server was released but this bug was not fixed. Will this problem be resolved in the nearest future?