Bug 31302

Summary: suexec doesn't execute commands if they're not in the current dir
Product: Apache httpd-2 Reporter: Michael Disserman <divisor>
Component: mod_cgiAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: REOPENED ---    
Severity: critical CC: bzasf, igor, mamrein+asfbug, rbb, rmiller
Priority: P3 Keywords: PatchAvailable
Version: 2.0.55   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: proposed fix

Description Michael Disserman 2004-09-19 21:36:11 UTC
(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>
Comment 1 Michael Disserman 2004-09-20 00:23:18 UTC
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.
Comment 2 Michael Disserman 2004-09-20 01:20:17 UTC
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.
Comment 3 Joshua Slive 2004-09-20 02:04:29 UTC
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.
Comment 4 Kaspar Brand 2005-03-13 11:42:59 UTC
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
Comment 5 Ryan Bloom 2005-03-13 13:25:10 UTC
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.
Comment 6 Kaspar Brand 2005-03-25 17:22:33 UTC
Created attachment 14563 [details]
proposed fix
Comment 7 Kaspar Brand 2005-03-25 17:23:36 UTC
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!
Comment 8 Kaspar Brand 2005-03-25 17:26:13 UTC
*** Bug 29534 has been marked as a duplicate of this bug. ***
Comment 9 Kaspar Brand 2005-04-03 09:01:09 UTC
PatchAvailable keyword added
Comment 10 Marco Amrein 2006-01-26 21:28:36 UTC
I can still confirm this issue for 2.0.55. I think it's getting time to bring
this fix to HEAD.
Comment 11 Igor R. 2008-06-06 02:15:47 UTC
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?