Bonjour à tous, je me pose la question du/des réel(s) avantage(s) de créer un user par site hébergé ?
J’en héberge quelques uns depuis quelques années, mais franchement mes hébergés ne s’en occupent pour ainsi dire jamais.
Auriez vous quelques arguments penchant pour cette option ? Peut-être un bénéfice en terme de sécurité ?
Qui que tu sois, je te remercie 
Qu’entend tu par «site hébergé» ?
Par installation WordPress ?
Mais en général c’est pour limiter la casse en cas d’intrusion sur ton serveur 
L’utilisateur principale des sites devrait plutôt être le ‘serveur web’ habituel (www-data), les users à ajouter seront simplement des users ayant accès pour les logs, des tâches de maintenance (ramasse miettes, dépose de fichiers via ftp, ou encore pour lancer des scripts ou des crons particulière).
D’après mois cloisonner les sites avec un utilisateur particulier ne renforce pas la sécurité car de toute façon l’utilisateur devra appartenir au groupe www-data (ou inversement) pour permettre au serveur web de servir le site.
Pour cloisonner de l’activité web il serait mieux de se tourner vers des solutions tel que Docker et LXC.
Pio c’est exactement ça.
Ok, merci, il ne font rien de tout ça, donc pas besoin que je cloisonne plus. En revanche merci pour les infos, je jetterai un œil
Il est d’autant plus important de bien séparer les sites hébergés que les mises à jour de sécurité ne sont pas faites sur ceux-ci !
Si les sites ne sont pas isolés en les mettant sous des identifiants utilisateur différents, il suffit qu’il y en ai un seul qui se fasse piratouiller et tous les autres sites sont compromis.
Pour que le contenu statique soit servi par apache, il faut que l’utilisateur www-data fasse partie des groupes client1 , client2 … clientX , oui. Enfin, disons que c’est la solution la plus facile.
Par contre c’est nimporte-quoi de dire que ce n’est pas secure !
Seul Apache tourne sous l’identité de l’utilisateur www-data et pourrait aller voir les fichiers dans les répertoires de n’importe-quel utilisateur/site. Mais il faudrait arriver à trouver un exploit et à hacker Apache pour lui faire faire cela.
Je veux dire, on ne fait pas faire tout et n’importe-quoi à Apache. On lui demande des pages web et il retourne des pages web et c’est tout. Si un vhost a été paramétré avec un site web dont la racine est /home/jbond/www/ , Apache n’ira jamais lire le fichier /home/jbond/secret.txt .
En revanche, du moment qu’il y a du contenu dynamique comme du PHP, comme on peut faire via le langage PHP à peu près toutes les bêtises possibles avec les droits d’un utilisateur, il est alors exclu que le PHP s’exécute sous l’identité de www-data .
Pour que le PHP s’exécute sous l’identité de site1 … siteX, il faut étudier des documentations telles que celle-ci et les appliquer. Mais cela demande un peu plus de boulot, c’est sûr.
Comment pensez-vous que les gros hébergements de type mutualisé type OVH / Online.net fonctionnent ?
Si n’importe-quel compte pouvait aller piocher les documents de n’importe-quel autre, ce serait vite un bazar incommensurable.
–
AnonymousCoward
'tain Clochette, t’as pris cher 
Non, il vaut mieux créer un utilisateur par site, cela renforce grandement la sécurité.
La gestion des permissions sous unix permet par exemple, de laisser en écriture les fichiers sur l’utilisateur (sur lequel tourne un php-fpm dédié, par exemple) et juste de la lecture pour les fichiers publics pour les données devant être délivrées par le serveur web (public assets).