Ta méthode marche mais elle ne répond pas à tout le problème :
1 - c'est toi qui gère les scrips cgi du client.. Dans mon cas, je peux laisser le client faire ces scripts cgi (puisqu'il a son propre compte).
2 - tu ne peux pas appliquer les quotas dans ton cas (n'oublies que les uploads sont dans le compte apache dans ton cas). Ce point est très important si le client à un acces en écriture via ftp par exemple ou s'il peut modifier les scripts php ou s'il peut réaliser des uploads etc, etc, ...
3 - dans ton cas, tu ne peux pas raisonnablement autoriser des binaires fournis par le client.
De plus si j'utilise les acl (c'est un domaine que je dois creuser) je peux authoriser ssh et donc les crontabs, les mysql_dump, etc, etc... j'autorise ssh uniquement avec acl sinon il est vraiment trop simple pour le client de voir les fichiers des autres sites (même ceux qui sont protégés via http par un fichier .htaccess).
Sinon, si les acl ne repondent pas au problème, je peux faire une conf d'apache mini (et minucieusement audité) qui troune sous le compte root et mettre les fichiers des sites non lisible pour les autres.
Les systèmes de sécurité de php sont satisfesants dans beaucoup de cas. Néanmoins pour les exisgences de certains clients suexec peut être indispensable.
> pas dans leur $HOME quoi !
$HOME n'est pas forcément utilisé par suexec.
Exemple :
<VirtualHost>
ServerName www.toto.com
User toto
Group website
DocumentRoot /var/www/html/www.toto.com/site/
php_flag engine off
AddHandler php-script .php
Action php-script /cgi-bin-local/php
ScriptAlias /cgi-bin-local/php "/var/www/html/www.toto.com/cgi-bin-local/php"
[...]
</VirtualHost>
Le site www.toto.com tourne sous le compte toto (les cgi du moins, il faut donc désactiver mod_php pour ce site et utilisé php en cgi).
/var/www/html/www.toto.com/cgi-bin-local/php est tout con :
#!/bin/bash
exec php $*
L'intérêt de ce petit wrapper est que le fichier php.ini utilisé par php est /var/www/html/www.toto.com/cgi-bin-local/php.ini. Ce qui permet de configurer php en fonction du site (ou du répertoire, etc...). Le problème est que les directives php_* dans httpd.conf ne marche pas pour php en cgi.
Le $HOME de toto peut être /home/toto. çà n'a aucune importance.
Par contre $HOME est utilisé lors de l'utilisation de UserDir :
UserDir public_html
L'ip de www.toto.com.localhost est 127.0.0.1.
Il reste à définir le virtual host www.toto.com.localhost (évidament non accessible de l'extérieur) comme fait au-dessus.
[^] # Re: Un nouveau serveur DNS libre : PowerDNS
Posté par matiasf . En réponse à la dépêche Un nouveau serveur DNS libre : PowerDNS. Évalué à 0.
Je crois que tu n'as pas bien compris.
Ta méthode marche mais elle ne répond pas à tout le problème :
1 - c'est toi qui gère les scrips cgi du client.. Dans mon cas, je peux laisser le client faire ces scripts cgi (puisqu'il a son propre compte).
2 - tu ne peux pas appliquer les quotas dans ton cas (n'oublies que les uploads sont dans le compte apache dans ton cas). Ce point est très important si le client à un acces en écriture via ftp par exemple ou s'il peut modifier les scripts php ou s'il peut réaliser des uploads etc, etc, ...
3 - dans ton cas, tu ne peux pas raisonnablement autoriser des binaires fournis par le client.
De plus si j'utilise les acl (c'est un domaine que je dois creuser) je peux authoriser ssh et donc les crontabs, les mysql_dump, etc, etc... j'autorise ssh uniquement avec acl sinon il est vraiment trop simple pour le client de voir les fichiers des autres sites (même ceux qui sont protégés via http par un fichier .htaccess).
Sinon, si les acl ne repondent pas au problème, je peux faire une conf d'apache mini (et minucieusement audité) qui troune sous le compte root et mettre les fichiers des sites non lisible pour les autres.
Les systèmes de sécurité de php sont satisfesants dans beaucoup de cas. Néanmoins pour les exisgences de certains clients suexec peut être indispensable.
> pas dans leur $HOME quoi !
$HOME n'est pas forcément utilisé par suexec.
Exemple :
<VirtualHost>
ServerName www.toto.com
User toto
Group website
DocumentRoot /var/www/html/www.toto.com/site/
php_flag engine off
AddHandler php-script .php
Action php-script /cgi-bin-local/php
ScriptAlias /cgi-bin-local/php "/var/www/html/www.toto.com/cgi-bin-local/php"
[...]
</VirtualHost>
Le site www.toto.com tourne sous le compte toto (les cgi du moins, il faut donc désactiver mod_php pour ce site et utilisé php en cgi).
/var/www/html/www.toto.com/cgi-bin-local/php est tout con :
#!/bin/bash
exec php $*
L'intérêt de ce petit wrapper est que le fichier php.ini utilisé par php est /var/www/html/www.toto.com/cgi-bin-local/php.ini. Ce qui permet de configurer php en fonction du site (ou du répertoire, etc...). Le problème est que les directives php_* dans httpd.conf ne marche pas pour php en cgi.
Le $HOME de toto peut être /home/toto. çà n'a aucune importance.
Par contre $HOME est utilisé lors de l'utilisation de UserDir :
UserDir public_html
http://127.0.0.1/~toto/(...) => /home/toto/public_html/
Les scripts cgi tourne sous le compte toto (si suexec est installé).
Enfin, on peut ausi appliquer suexec par répertoire (ici http://hostname/www.toto.com/(...) ):
ProxyPass /www.toto.com/ http://www.toto.com.localhost/(...)
ProxyPassReverse /www.toto.com/ http://www.toto.com.localhost/(...)
L'ip de www.toto.com.localhost est 127.0.0.1.
Il reste à définir le virtual host www.toto.com.localhost (évidament non accessible de l'extérieur) comme fait au-dessus.
PS : Il existe d'autre solutions que suexec...