On Sun, Apr 28, 2002 at 10:55:59AM -0700, Justin Erenkrantz wrote:
> This is a message from the person who originally filed PR 7810.
> I am not familiar enough with mod_cgid to verify his patch or
> to get suexec working with worker. -- justin
Just to clarify , the patch below doesnt fix it at all :-), it's
really just an addendum to the "userdir" patch to the ugid
structure that was committed a few days ago.
Actually, I'm not entirely sure why mod_cgid insists on reading/writing
the elements individually, it'd be (slgihtly) more efficient and
just as effective to simply:
send_req(...
write(fd, &suexec_cfg, sizeof(suexec_cfg));
get_req(...
rc = read(fd, &suexec_cfg, sizeof(suexec_cfg));
if(rc != sizeof(suexec_cfg) {
return 1;
}
which would be a bit more future-proofed, but anyway ..
As I said, I'm continuing to look into the problem, I'm not entirely
certain if it is a mod_cgid problem. By the time send_req is being
called (send_req is where the handler actually resends the request
accross the local socket) suexec_cfg.active is not 1, so the
"server/cgid" end of the equation is quiet correct to not try and
use suexec.
Additionaly the uid and gid are simply set to 1 (which I think is
their initial default, and the userdir flag to random memory), the
suexec_cfg stuff never seems to get set at any stage. It seems
that by the time the mod_cgid handler has been called the problem
has already occurred.
It seems that somehow changing mod_cgi -> mod_cgid, or prefork -> worker
means that the mod_suexec cfg stuff never happens. I'm not familiar
at all with the codebase which is why this is all taking me so long,
but afaict the only place in the code that ever does set active to 1
is set_suexec_ugid in mod_suexec.c, that doesnt make much sense to
me because this is a configuration handler. Function pointers and
code divergency make it pretty hard to track down how exactly
(with prefork and mod_cgi) active ever gets set to 1, because I'm
pretty sure this is the step that's failing.
I'm fairly certain from gleaning over the mod_cgid code that in
order for it to work correctly for userdir, it will probably
need to do a chdir to the correct directory before constructing
the child process, but that's a comparitively trivial problem.
Anyway, that's simply a summary of what I have to date.
> Anyway, this patch is definitely something that's needed at some stage :
>
> Index: mod_cgid.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/generators/mod_cgid.c,v
> retrieving revision 1.128
> diff -u -r1.128 mod_cgid.c
> --- mod_cgid.c 22 Apr 2002 08:08:38 -0000 1.128
> +++ mod_cgid.c 28 Apr 2002 13:14:55 -0000
> @@ -337,6 +337,10 @@
> if (rc != sizeof(gid_t)) {
> return 1;
> }
> + rc = read(fd, &suexec_cfg->ugid.userdir, sizeof(int));
> + if (rc != sizeof(int)) {
> + return 1;
> + }
> rc = read(fd, &suexec_cfg->active, sizeof(int));
> if (rc != sizeof(int)) {
> return 1;
> @@ -443,6 +447,7 @@
> write(fd, &suexec_mod->module_index, sizeof(int));
> write(fd, &suexec_cfg->ugid.uid, sizeof(uid_t));
> write(fd, &suexec_cfg->ugid.gid, sizeof(gid_t));
> + write(fd, &suexec_cfg->ugid.userdir, sizeof(int));
> write(fd, &suexec_cfg->active, sizeof(int));
> }
>
>
> it's just to integrate the change you made to the ugid structure
> to mod_cgid.
--
[EMAIL PROTECTED] [EMAIL PROTECTED]
