[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [users@httpd] Re: mod_suexec with mod_userdir and fcgid (webapps in subdirs with separated user context)

Hi Luca,

thanks for your valuable feedback. With your help I finally found a
solution. It feels like a dirty hack, but it works ;)

Am 24.04.2018 um 10:36 schrieb Luca Toscano:
>>     Do you have a good idea why php-cgi7.0 throws the following error when
>>     used with mod_fcgid, mod_usermod and mod_suexec?
><     uid: (1002/webapp1) gid: (1002/webapp1) cmd: php-fcgi-starter cannot get
>>     docroot information (/var/www/webapp1)
>>     $ ls -al /var/www/webapp1
>>     drwxr-xr-x 9 root root 4096 Jun 29  2014 .
>>     drwxr-x---  2 webapp1 webapp1  4096 Nov  7 15:14 php-fcgi
>>     drwxr-x---  2 webapp1 webapp1  4096 Apr 11  2015 www
>>     [...]
>>     The same setup works perfectly fine without mod_usermod (i.e. when the
>>     whole VHost has a dedicated suexec user). Only with mod_usermod, we get
>>     this strange error.
> Premise: I am super ignorant about suexec & C, but this snippet of code
> in suexec.c seems to be the one returning the error:
>     if (getcwd(cwd, AP_MAXPATH) == NULL) {
>         log_err("cannot get current working directory\n");
>         exit(111);
>     }
>     if (userdir) {
>         if (((chdir(target_homedir)) != 0) ||
>             ((chdir(AP_USERDIR_SUFFIX)) != 0) ||
>             ((getcwd(dwd, AP_MAXPATH)) == NULL) ||
>             ((chdir(cwd)) != 0)) {
>             log_err("cannot get docroot information (%s)\n",
> target_homedir);
>             exit(112);
>         }
>     } 
> As far as I can see, this is what it tries to do:
> - save the current working dir to 'cwd'
> - change dir to "target_homedir", that should be in this
> case /var/www/webapp1
> - change dir to AP_USERDIR_SUFFIX, that if not re-defined should be
> "public_html" (#define AP_USERDIR_SUFFIX "public_html" in suexec.h)

Which seems like a bug to me. mod_userdir explicitly allows to change
the default path to userdir and suExec should take that into account
instead of hardcoding AP_USERDIR_SUFFIX at compile-time.

> - set the variable 'dwd' (docroot working directory) to the above
> - change dir back to cwd (current working directory) 
> So I'd try to add a public_html directory and see how it goes.

Indeed, that helped! I created /var/www/webapp1/public_html as empty
directory. Next error I got was:

[2018-05-10 00:27:34]: command not in docroot

Which comes from the following code in suexec.c:

    if ((strncmp(cwd, dwd, strlen(dwd))) != 0) {
        log_err("command not in docroot (%s/%s)\n", cwd, cmd);

So next step was to replace the newly created directory with a symlink:

$ ln -s php-fcgi /var/www/webapp1/public_html

and replace

    FCGIWrapper /var/www/webapp1/php-fcgi/php-fcgi-starter .php


    FCGIWrapper /var/www/webapp1/public_html/php-fcgi-starter .php

in the VHost config. Unbelievable, but that finally worked. My PHP apps
now run with php-fcgi as the userdir user 'webapp1' by suExec. Yay!

So it seems like I have to trick suExec twice to get it working with
mod_userdir and a custom userdir path:

1. create subdir public_html inside home directory of my suExec user
2. make public_html a symlink to the dir where the php-fcgi starter
   script resides and run it from theere as suExec otherwise refuses to
   run the script.

Thanks a ton. I'm still not 100% sure whether I do it the right way, but
it occurs to me as if I just discovered two bugs in Apache2 suExec that
make crazy workarounds necessary.

What do you think?


Attachment: signature.asc
Description: OpenPGP digital signature