Bonjour à tous !

j'ai installé un serveur sous debian8, apache2, Php7, et pour faire un semblant d’hébergement mutualisé, j'utilise le mod userdir.

mais, voilà donc une super faille : les scripts php peuvent fouiller toute l'arborescence... et évidemment, je veux limiter à chaque dossier utilisateur /home/(utilisateur)/public-html/

la solution semble être du coté des mods suexec et suphp, ou l'on trouve suffisamment de doc pour php5, mais pour php7, je suis loin de trouver mon bonheur.

est-ce que l'un d'entre vous a réalisé cette manip et pourrait me guider svp ?

Bonjour,

suexec et suphp sont des modules Apache, ils devraient fonctionner sans problème avec PHP 7 et la doc est à mon avis exactement la même qu'avec PHP 5.

merci de ta réponse.

Il est vrai que la dernière version de suphp est compatible php7

j'ai tenté de compiler, mais c'est là que je bloque.

j'ai l'impression que je ne vais pas pouvoir me contenter de l'installation d'apache à partir des repository (apt-get), et que je vais devoir le compiler moi-même. serait-ce le secret pour arriver à mes fins ?

avant de refaire tout de ce coté là, un avis éclairé sur cette question me rassurerait

Bonjour,

Pour un déploiement secure et scalable de PHP, je recommande php-fpm, cela fonctionne en fastcgi donc avec n'importe quel serveur supportant fastcgi. Le principe est que PHP est exécuté dans un processus distinct d'apache, et chaque site peut être exécuté avec un utilisateur différent, du chroot, des droits particuliers, une configuration spécifique, etc. Du côté apache, le module pour s'y interfacer est apache-fastcgi. On peut aussi mettre apache de côté et utiliser nginx.

J'aurais tendance à dire que suphp et suexec c'est franchement dépassé comparé à ce type de solutions.

Cordialement

merci Sékiltoyai pour ton retour !

je vais suivre ton conseil et m'orienter vers php-fpm !

Bonjour !

un petit retour après les vacances... et constatation d'un petit "détail" que j'aimerai optimiser ^^

en gros, depuis que j'utilise php-fpm, arrétez-moi si je me trompe :
- les fichiers php sont servis et interprétés par php-fpm
- les autres fichiers (html, txt, htaccess...Etc...) continuent à être traités par apache sans passer par php-fpm

résultat : les uns dépendent des droits de l'utilisateur définit pour mon pool, et les autres dépendent des droits de www-data... ce qui me gène ^^

exemple :
j'ai un utilisateur qu'on va appeler "userlambda", qui heberge un site sur mon serveur, dans "/home/userlambda/public_html/".
il se logue en ftp avec ses identifiants userlambda:motdepasselambda, et dépose son code dans ce repertoire.
ses fichiers appartiennent alors à l'utilisateur userlambda et au groupe userlambda. Ce qui est très bien.
lorsqu'on accede à http://userlambda.domainelambda.com :
- les fichiers php sont traités par php-fpm pour l'utilisateur userlambda
- les autres fichiers sont traités par apache avec l'utilisateur www-data

j'aurai aimé que l'utilisateur userlambda soit également utilisé pour tout ce qui est autre que php (.htaccess, robots.txt...etc...)

est-ce que j'ai mal fait quelquechose ? est-ce le fonctionnement normal ? comment faites-vous, vous ?

(pour le moment, j'ai mis www-data dans le groupe userlambda, et demandé à mon utilisateur de mettre des autorisations 640 à ses fichiers... mais ce n'est pas une solution qui me plait ^^)

Bonjour,

C'est un problème classique avec l'utilisation de apache2 + php-fpm, mais qui heureusement n'est pas insoluble. Au passage, tu aurais probablement eu le même problème à régler avec mod_suexec.

De souvenir, cela fonctionnait plutôt bien avec des ACL étendues, ce sont des droits additionnels que tu places sur les fichiers et qui te permettent de pouvoir les rendre accessibles par plusieurs utilisateurs ou groupes.

Dans mon cas, j'utilisais cette ACL : Elle fixe les droits de l'utilisateur www-data à rwX (rw sur les fichiers, rwx sur les dossiers), aussi bien sur les fichiers actuels que futurs (mot clé default) dans le dossier /var/www/, et cela récursivement pour que cela s'applique sur les fichiers existants. Dans ce cas, l'utilisateur www-data avait donc les droits d'accès, lecture et écriture sur tous les fichiers créés par les autres utilisateurs, et ce, même si les utilisateurs exécutent des opérations sur les droits (chmod).

Pour que les ACL étendues fonctionnent, il faut que le système de fichiers les supporte (pas de problème si le FS est ext3 ou ext4) et il ne faut pas oublier de les activer lors du montage du système de fichier, en passant l'option acl dans les options de montage du fs, très probablement dans /etc/fstab : Dans le cas où cette solution ne fonctionnerait pas, le fait de mettre www-data dans le groupe de l'utilisateur peut être contraignant mais ce n'est pas une mauvaise solution. En tout cas elle ne pose pas de problème de sécurité quant à l'isolation des sites. Il suffit de régler le serveur FTP pour définir le umask par défaut des fichiers en 0640, ce qui ne demande aucune action de l'utilisateur (lequel au passage ne devrait pas avoir à toucher aux droits de ses fichiers).

Cordialement

ok. encore un grand merci !

pour ma prochaine install de serveur, est-ce que nginx permet de gérer mieux ces choses là ?

Bonjour,

Je recommande chaudement nginx, qui est globalement plus simple à configurer (sauf exceptions) et marche assez bien avec php-fpm, en particulier parce que le protocole fastcgi est supporté de base (c'est peut être le cas maintenant sur Apache ceci dit).

Mais pour ce cas précis nginx et Apache se comporte de la même manière, le user est global au serveur, et ensuite nginx spawne des worker avec ce même user, donc pas de séparation des droits, sauf directive de configuration que je n'aurais pas vu.

Après, s'il y a peu d'utilisateurs et un trafic significatif pour chaque site, il est toujours possible de lancer un nginx léger par utilisateur, voire de placer chaque user dans un container LXC distinct.

Cordialement