You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Colm MacCárthaigh <co...@Redbrick.DCU.IE> on 2002/05/21 02:03:03 UTC

[PATCH] exec cmd working with suexec

The following patch reverts to the previous and documented
bevahiour (exhibited by 1.3). Currently <!--exec cmd
does not work with suexec enabled as the proc.c will try to
run : shell -c suexec uid gid ... so on.

Index: os/unix/unixd.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/os/unix/unixd.c,v
retrieving revision 1.52
diff -u -r1.52 unixd.c
--- os/unix/unixd.c	17 May 2002 11:33:10 -0000	1.52
+++ os/unix/unixd.c	20 May 2002 23:59:53 -0000
@@ -357,6 +357,15 @@
     newargs[2] = execgroup;
     newargs[3] = apr_pstrdup(p, progname);
 
+    /* 
+    ** using a shell to execute suexec makes no sense thus
+    ** we force everything to be APR_PROGRAM, and never
+    ** APR_SHELLCMD
+    */    
+    if(apr_procattr_cmdtype_set(attr, APR_PROGRAM) != APR_SUCCESS) {
+        return APR_EGENERAL;
+    }
+
     i = 0;
     do {
         newargs[i + 4] = args[i];

Re: [PATCH] exec cmd working with suexec

Posted by Colm MacCárthaigh <co...@Redbrick.DCU.IE>.
On Tue, May 21, 2002 at 01:03:03AM +0100, Colm MacCárthaigh wrote:
> The following patch reverts to the previous and documented
> bevahiour (exhibited by 1.3). Currently <!--exec cmd
> does not work with suexec enabled as the proc.c will try to
> run : shell -c suexec uid gid ... so on.
> 
<snip patch>

I should have mentioned, this patch resolves PR 8291. Also
after applying this patch, SSI + suexec works fully except
that

<!--#include file="some.cgi"-->

will run the cgi as the webserver user, and not the suexec
user. Obviously a security hole. "include virtual" is not
affected, Nor is the fsize directive. (they all use 
subrequests)

The patch below fixes it by using the ap_sub_req_lookup_uri
instead of ap_sub_req_lookup_file. Since the functionality of
_uri is a superset of _file (afaict) this means that nothing
valid in an "include file" directive will break. But it
also means that some of what was previously invalid will
(query string etc). Since "include file" has deprecated
support anyway .. I'm not sure how big a deal it is that
mod_include wouldnt be enforcing what "include file" should 
only be able to do.

Colm

Index: modules/filters/mod_include.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.222
diff -u -r1.222 mod_include.c
--- modules/filters/mod_include.c       17 May 2002 11:33:09 -0000      1.222
+++ modules/filters/mod_include.c       22 May 2002 09:26:39 -0000
@@ -1263,7 +1263,7 @@
                                     "in parsed file %s";
                     }
                     else {
-                        rr = ap_sub_req_lookup_file(parsed_string, r, f->next);
+                        rr = ap_sub_req_lookup_uri(parsed_string, r, f->next);
                     }
                 }
                 else {