Apache, suexec, PHP, suPHP

Bien que je sois assez à l'aise en tant qu'utilisateur Linux , mon Admin-fu Linux est un peu faible. Ainsi, je suis ici à la recherche de conseils avec un serveur CentOS que je suis sur le point de construire.

J'ai besoin de configurer un serveur Web Apache2 pour certains de nos clients. Je veux que le contenu Web de chaque client soit sous son répertoire personnel ( USERDIRdans apache.conf, non?) Pour les sites HTML statiques. Je veux qu'Apache s'exécute en tant que client ( suexec?). Certains de leurs trucs seront des applications PHP et j'ai l'impression que je vais aussi vouloir les regarder suphp.

Donc, fondamentalement, je veux ressembler à une petite version d'une société d'hébergement Web partagé. Considérant comment commun les sont , je pensais que je serais facilement trouver un courant agréable guide pratique sur la mise en place tout cela , mais jusqu'à présent , je l' ai eu très peu de chance. Je soupçonne que mes mots de recherche sont désactivés.

Donc, les questions (n'hésitez pas à répondre à tout ou partie):

1. Quelqu'un a-t-il des liens solides vers des guides actuels / modernes qui pourraient m'aider à tout mettre en place? Non, le site de documentation d'apache n'est pas un guide ;-)
2. Puisque j'ai un mélange de sites statiques et d'applications PHP, est-ce que je veux / ai besoin que suexec et suphp soient installés? Si oui, cela pose-t-il des problèmes dont je devrais être conscient?
3. Dois-je envisager d'autres options au lieu de suexec et suphp?

Je prévois de donner aux utilisateurs finaux SSH, SFTP ou SCP un accès à leurs contenus (si cela affecte quoi que ce soit).

Merci d'avance pour votre aide.

[Modifier] J'aurais dû le mentionner plus tôt: Un objectif clé de ma quête pour émuler un fournisseur d'hébergement partagé lié aux autorisations de fichiers et à la propriété. J'aimerais vraiment éviter d'enseigner aux utilisateurs la nécessité de changer de telles choses juste pour voir leurs ajouts / changements.

L'utilisation de suexec et suphp applique un type de séparation de privilèges différent de celui par défaut.

La valeur par défaut consiste à séparer l'autorisation de l'utilisateur du serveur Web. En d'autres termes, l'utilisateur est propriétaire des fichiers et doit accorder au serveur Web l'autorisation de les afficher et de les modifier.

Le modèle suexec / suphp est que le serveur Web (lors de l'exécution de scripts) s'exécute sous le compte de l'utilisateur, donc le site Web a l'autorisation de faire tout ce que l'utilisateur a l'autorisation de faire. Dans une certaine mesure, cela supprime la séparation entre l'utilisateur et le serveur Web, mais en échange, il impose une séparation DIFFÉRENTE: c'est-à-dire entre le site Web d'un utilisateur et le site Web d'un utilisateur différent sur la même boîte.

Par défaut, PHP s'exécute toujours sous le compte utilisateur d'Apache, de sorte que les scripts PHP d'un site Web peuvent accéder à tous les fichiers que les scripts PHP d'un autre site peuvent. Par conséquent, si un compte sur le serveur est piraté, l'infection peut se propager aux autres. SuPHP empêche cela.

Ni suexec ni suphp n'affecteront la façon dont apache sert le contenu statique . Toutes les anciennes règles s'appliquent toujours. Au lieu de cela, suexec et suphp modifient le compte sous lequel CGI et PHP (respectivement) s'exécuteront. Suexec fait exécuter l'exécutable CGI sous le compte du propriétaire, tandis que SuPHP fait exécuter les scripts PHP sous le compte du propriétaire.

Suexec et SuPHP ne sont pas nécessairement meilleurs . Ils sont juste différents . Ils ne vont pas empêcher un site d'être piraté (et pourrait sans doute rendre le site plus facile à pirater), mais ils empêcheront un compromis sur un seul site de se propager à tous les autres. Pour l'administrateur du site, cet isolement est sans doute plus important, c'est pourquoi certains systèmes d'hébergement partagé font de suexec et suphp la valeur par défaut.

Un "piège" extrêmement courant est que SuPHP vérifie la propriété et les autorisations d'un script avant son exécution, et renvoie une erreur 500 si les autorisations ne sont pas appropriées.

En particulier:

• Le propriétaire et le groupe du fichier doivent correspondre au propriétaire du site Web (comme paramètre dans la configuration d'apache)
• Le fichier ne doit pas être accessible en écriture
• Le répertoire parent ne doit pas être accessible en écriture universelle