Bon petit explicatif du pourquoi du comment suexec du serveur web posait problème...

Donc quand j'ai pris la suite de zed qui devait partir il m'a donné le message d'erreur du suexec.log qui était pour le moin "nul" :

emerg: cannot get docroot information (/space_3)


Sa veut tout et rien dire ! Quand on regarde le code de suexec.c :

   if (userdir) {
       if (((chdir(target_homedir)) != 0) ||
           ((chdir(USERDIR_SUFFIX)) != 0) ||
           ((getcwd(dwd, AP_MAXPATH)) == NULL) ||
           ((chdir(cwd)) != 0)) {
           log_err("emerg: cannot get docroot information (%s)\n",
                   target_homedir);
           exit(112);
       }
   }
   else {
       if (((chdir(DOC_ROOT)) != 0) ||
           ((getcwd(dwd, AP_MAXPATH)) == NULL) ||
           ((chdir(cwd)) != 0)) {
           log_err("emerg: cannot get docroot information (%s)\n", DOC_ROOT);
           exit(113);
       }
   }


On voit que c'est le "else" qui nous concerne (on utilise pas UserDir du httpd.conf) ! Donc là ben 3 possibilités d'erreurs principales et une seul message d'erreur... Donc question debug c'est naz...

Bref ni une ni deux je retouche le code histoire d'en savoir un peu plus quand même parcque y a pas de raison apparente que suexec merde !

je remplace donc :

   if (((chdir(DOC_ROOT)) != 0) ||
           ((getcwd(dwd, AP_MAXPATH)) == NULL) ||
           ((chdir(cwd)) != 0)) {
           log_err("emerg: cannot get docroot information (%s)\n", DOC_ROOT);
           exit(113);
       }

par :

           if(chdir(DOC_ROOT) != 0) {
                   log_err("unistd error code chdir : (%d)(%d)(%d)(%d)(%d)(%d)(%d)(%d)(%d)(%d)\n", EACCES, EFAULT, EIO, ELOOP, ENAMETOOLONG, ENOENT, ENOMEM, ENOTDIR, EACCES, EBADF);
                   log_err("emerg: 1 cannot get docroot information (%s):(%d)\n", DOC_ROOT, errno);
                   exit(113);
           } else if (getcwd(dwd, AP_MAXPATH) == NULL) {
                   log_err("emerg: 2 cannot get DWD CMD (%s):(%d)\n", dwd, errno);
                   exit(113);
           } else if (chdir(cwd) != 0) {
                   log_err("emerg: 3 cannot get cwd information (%s):(%d)\n", cwd, errno);
                   exit(113);
           }
   }

Je pense que se sera quand même plus sympat ;) Enfin après une tite compile je remplace le précédent suexec qui est tjrs là sous le nom de suexecold (en cas de plantage suffit d'écraser l'autre puisqu'une copie peut être copié depuis /root/ben1/apache_***/src/support/).

Et là je vois que la variable d'erreur errno sort la valeur 13 !!! (donc EACCES)

Il y aurait donc un problème de droit qui déconne et sur /space_3 en plus :''

Du coup je regarde les droits (j'avais déjà fait avant mais bon on est jamais trop prudent ;p) et je vois 705 donc en théorie pas de problème ! Ba oui suexec est compilé pour se lancer en nobody au début donc il a une perm de 5 :

-D DOC_ROOT="/space_3"
-D GID_MIN=100
-D HTTPD_USER="nobody"
-D LOG_EXEC="/var/log/httpd/suexec.log"
-D SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D SUEXEC_UMASK=073
-D UID_MIN=100
-D USERDIR_SUFFIX="public_html"

Puis il va switch sur le uid gid de l'utilisateur en prennant donc un truc genre xxx:1001

ET là malheure on voit que /space_3 est en 1001 pour le groupe. Donc quand on appelle chdir de la libc pour demander à entrer dans /space_3 alors que les perm pour le groupe sont à 0 ben normal sa déconne... Et sa MEME si other a des droits bien sur ;)

Ouai ok mais alors pourquoi sa fait pas pareil quand on est dans le rep de l'utilisateur par la suite ! Ba simplement parcque là on bénéficie des droits utilisateurs bien sur qui sont à 7 !

Donc ben suffit de donner au moins le droit de parcour au groupe sur le rep /space_3 donc passer à 715 !

Et hop magique sa marche ;)

Voilà le résumé de la manip... C'était donc pas bien compliqué mais le message de debug "merdique" de suexec pouvait franchement pas trop aider.

ben1