SuPHP / suEXEC / php en cgi

[glibre]

Bonjour,

je fouine en ce moment sur SuPHP / suEXEC / php en CGI.. et je me demande qu'est il le mieux:

- en terme de securite

- en terme de performance

et pourquoi utiliser l'un ou l'autre...

Avez vous un retour d'experience dessus?

merci

[AvenueDuWeb]

Bonjour,

je fouine en ce moment sur SuPHP / suEXEC / php en CGI.. et je me demande qu'est il le mieux:

- en terme de securite

- en terme de performance

et pourquoi utiliser l'un ou l'autre...

Avez vous un retour d'experience dessus?

merci

<{POST_SNAPBACK}>

Alors php en cgi sans installer SuPHP ou phpSuexec je suis pas sûr que ça ait une réelle utilité (ça doit certainement en avoir, mais je ne la connais pas). Il me semble qu'en plus php en cgi est moins bien niveau sécurité que compilé en mod apache.

Mis à part ça j'ai installé suPHP pour tous mes clients, et j'en suis très content, un peu surpris par les performances, car je n'ai pas remarqué réellement de baisse de performance contrairement à ce qui se dit. Installer suPHP ça a un avantage, un script ne peut pas toucher aux fichiers dont il n'a pas les droits. L'exemple du virus phpBB est bien pour ça, sans suPHP tout le disque dur pouvait être effacé, avec logiquement c'est impossible, ça effacera au pire tous les fichiers du domaine (donc tout le site). Enfin en tout cas c'est ce que j'ai compris. Ca apporte donc un petit plus au niveau sécu. Bon bien sûr l'avantage principale c'est au niveau des UID. Par contre il faut adapter, adieu les php_flag et php_value dans les htaccess, il faut mettre tout cela dans un fichier php.ini (pour chaque domaine), adieu les CHMOD 777 (suPHP les interdit)... Rien de très "chiant", mais ça fait un petit peu de boulot en plus. Sinon pas essayé phpSuexec, donc je ne peux pas comparer.

Si ton soucis c'est juste les UID, et que tu n'as que quelques domaines sur ton serveur, la solution la plus avantageuse en terme de perfs, serait de mettre php en cli, et de lancer une tâche cron toutes les x heures pour redonner les droits sur les fichiers uploadés en php.

@+

[glibre]

merci pour ta reponse.

par contre, j'ai lu que cela posait des probleme avec le mod_userdir

le confirmes tu? (avant que je ne me casse les dents dessus)

je suis sous Debian, et la version stable est la 0.5.2-3

Or la 0.6 existe...

La aussi, y a t il une reelle difference ?

(pas super envie de mettre des packets unstable)

[AvenueDuWeb]

merci pour ta reponse.

par contre, j'ai lu que cela posait des probleme avec le mod_userdir

le confirmes tu? (avant que je ne me casse les dents dessus)

je suis sous Debian, et la version stable est la 0.5.2-3

Or la 0.6 existe...

La aussi, y a t il une reelle difference ?

(pas super envie de mettre des packets unstable)

<{POST_SNAPBACK}>

Je n'ai pas installé le mod userdir donc je peux pas te dire. Sinon je suis sous la version 0.5.2 de php, car je n'ai jamais réussi à installer la version 0.6.0. Sinon tu peux très bien compiler toi même le tar.gz sans passer par le paquet deb, suphp est pas extrêment complexe à installer (en tout cas la version 0.5.2).

Je ne sais pas si tu as un panneau d'admin ou des webmails mais je sais que certains réclament l'interpréteur php en cli (directadmin par ex). Donc je te conseille de configurer suphp pour utiliser l'interpréteur php.cgi (par ex, tu peux l'appeler autrement) et de garder php compilé en mod apache en plus (pour ça tu copies ton interpréteur php vers php.cli, tu recompiles php en mod cgi, tu copies le nouvel interpréteur php vers php.cgi et tu remets le fichier php.cli à la place du fichier php). Ensuite tu fais ./configure --prefix=/usr --with-php=/usr/bin/php.cgi (enfin selon le chemin de l'interpréteur php cgi).

Je pense que si Dan passe par là il pourra t'aider plus que moi, car je crois qu'il a essayé les 2 (suexec et suPHP) et qu'il sera sans doute t'expliquer bien mieux que moi. Mais cela dit, si t'as besoin d'aide ou des questions j'essaierai d'y répondre.

Sinon je ne suis pas sous Debian, donc je ne sais pas comment fonctionne l'installation en packet deb (je suppose que c'est un packet deb vu la version que t'indiques) @+

[glibre]

re--

j'ai installé suphp 0.6 a partir des sources... et ca marche pas mal.

deplus, il m'est possible de mettre le php5 en plus du php4 en cgi.

(il suffit de preciser .php pour la v4 et .php5 pour la v5)

par contre, je n'arrive plus a utiliser le php4 en module...

avec le SuPHP (il me semble que je le pouvais avant...)

mais c'est pas grave, car je peux toujours determiner au niveau du virtualhost

si je souhaite utiliser SuPHP ou pas ...

un simple

echo exec('whoami');

confirme bien s'il est activé ou pas.

je suis egalement obligé de renseigner suPHP_UserGroup pour dire avec quel utilisateur

le script doit etre executer...

S'il y a une explication... je suis preneur

Sinon, tu as des exemples / conseils d'utilisation? (pour la securite, performence, autre)

merci pour tes reponses

[AvenueDuWeb]

je suis egalement obligé de renseigner suPHP_UserGroup pour dire avec quel utilisateur

le script doit etre executer...

S'il y a une explication... je suis preneur

Sinon, tu as des exemples / conseils d'utilisation? (pour la securite, performence, autre)

merci pour tes reponses

<{POST_SNAPBACK}>

Alors pour le suPHP_UserGroup je crois que c'est spécifique à la version 0.6.0, c'est en partie parce que suphp est devenu bcp plus complexe avec la nouvelle version que je m'en suis pas trop occupé. Donc là-dessus je peux pas t'aider. Je sais que la version 0.6.0 a été moyennement appréciée par pas mal de personnes (y'a qu'à lire leur mailing list qui d'ailleurs est plutôt active en cas de problème) pour ces raisons je crois.

Sinon pas de conseils d'utilisation, je ne suis pas encore un grand expert de suphp.

@+

[Elgi]

Bonjour,

je fouine en ce moment sur SuPHP / suEXEC / php en CGI.. et je me demande qu'est il le mieux:

- en terme de securite

- en terme de performance

et pourquoi utiliser l'un ou l'autre...

Avez vous un retour d'experience dessus?

merci

<{POST_SNAPBACK}>

Cela n'engage que moi, mais je dirais qu'il est mieux de savoir patcher apache selon son besoin et donc de pouvoir offrir php en cgi par exemple tout en y intégrer quelques régles de sécurité.

Maintenant, pour suphp, il permet d'utiliser php en cgi entre autre. La grande différence entre la version 0.6.0 et les précédentes résident surtout que suphp-0.6.0 permet d'utiliser plusieurs versions de php en cgi, et gére également les cgi. Cette différence fait que beaucoup d'utilisateur de suphp-0.5.2 se perdent lors de l'installation devenu un brin plus compliqué et l'apparition d'un fichier de configuration pour suphp accentue ce phénome.

Niveau des performances, si un script php a besoin de mémoire, et bien en version cgi, cela n'impacte pas les process suivant d'apache et donc on a un économie de mémoire pour apache. A contrario, php en module d'apache, si un process apache a besoin de mémoire, cela sera répercuté sur les process suivant.

php en cgi permet d'identifier rapidement quel script est "méchant" au besoin. on peux donc effectuer des contrôles plus fin, killer le script php, avertir son propriétaire en lui donnant le nom du script.

php en cgi évité aussi de devoir recompilé apache et php dés que l'un des deux doit être upgrader.

ps : pas vu de post sur la derniére version d'apache-1.3.34 datant du 17-Oct-2005, pensez à faire vos mises à jour.

[Dan]

ps : pas vu de post sur la derniére version d'apache-1.3.34 datant du 17-Oct-2005, pensez à faire vos mises à jour.

J'ai répondu dans le post où tu en as parlé