En effet, si on fait tourner l'Apache en utilisateur www-data (groupe www-data), celui-ci doit servir les pages statiques sous ce compte, mais il doit également servir les pages dynamiques (CGI, php, etc.). Et là, c'est le vrai problème puisque comment régler les permissions sur les fichiers de configuration d'une application php contenant une liste d'identifiants/mots de passe ?

On ne veut pas mettre ces fichiers en World readable puisqu'ils sont sensibles. Si les utilisateurs ne sont pas inclus dans le groupe www-data et que le ~/public_html/ possède le bit SetGroupID, les utilisateurs peuvent alors choisir de n'accorder le droit de lecture qu'à eux-même, ainsi qu'au groupe www-data, empêchant aux autres users la possibilité de lire ces fichiers importants.

Le problème, c'est qu'un utilisateur dans un autre virtual host peut accéder à ces fichiers via l'éxécution de code par le serveur Apache puisque le daemon tourne toujours en www-data:www-data quelque soit le virtual host !

La solution précédente est donc nulle.

Apache avait prévu le coup en offrant la possibilité de modifier son identité lors de l'éxécution de script CGI en prenant les privilèges du propriétaire du fichier désiré. Cette solution, appelée suxexec, parait convenable... lorsqu'on arrive à la mettre en place dans un environnement d'hébergement ! Son installation et configuration sont très lourdes puisqu'elle nécessite de compiler le binaire à chaque changement de paramètre. De plus, à l'éxécution par Apache, ce programme est très à cheval sur la rigueur des paramètres passés en paramètre...

suxexec fonctionne très bien pour les CGI mais reste cantonné à ces scripts (vous savez, les programmes mis dans /cgi-bin/ par défaut). Malheureusement, cela ne correspond aux besoins de l'utilisateur qui veut du PHP dans ~/public_html/.

Une solution serait de rendre tous les scripts PHP en tant que CGI (en les rendant "éxécutables" et en utilisant binfmt pour rendre les choses à peu près transparentes) et d'autoriser l'éxécution de script dans toute la hiérarchie ~/public_html/, ce qui est très fortement déconseillé pour des raisons de sécurité (dixit la documentation d'Apache, bien que quelques unes de ces raisons ne soient plus valables à l'heure actuelle).

Le coup de transformer les fichiers PHP en CGI est bien, mais beaucoup trop contraignante pour les [l]users et a un impact sur les performances. Donc que faire ?

Le projet suPHP semble répondre à toutes les attentes d'un administrateur : il acquiert l'UID et GID du propriétaire du fichier PHP. Malheureusements il y a assez peu de feedback sur ce module. Par exemple, à l'heure actuelle, il n'y a pas d'étude sur la sécurité de ce système (qualité du code) ou sur ses performances.

Bref. C'est que j'utilise depuis quelques jours et celà semble marcher comme il faut. À voir avec le temps...