J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Quelle est la finalité de tout ça ?
Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?
Ce qui se pratique habituellement c'est de créer un vhost par
site/appli avec la racine
("DocumentRoot" pour Apache, "root" pour Nginx) correctement positionnée.
C'est le cas.
Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
dossier racine.
Oui.
Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié
par site/appli.
C'est fait ou en cours d'être fait. Oui.
Si on veut être encore plus robuste, on peut créer un conteneur
(Docker, LXC, autre)
par site/appli.
Totalement surchargé avec cela, trop de besoins d'apprentissage sur
l'ensemble, je ne sais gérer Docker et encore moins LXC.
On peut aussi créer un serveur par site/appli, mais là ça devient
vraiment lourd pour
pas grand-chose.
Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans
d'apprentissage pour arriver à la conclusion que nous sommes dépassés.
Si un script est dangereux et ne devrait pas être exploitable à
distance, alors il faut
le sortir de la racine ou ajouter une directive spécifique pour que le
serveur Web refuse
de servir les requêtes qui arrivent dessus.
Oui cela semble logique :)
Un outil dangereux, on ne le conserve pas !
Mais au final, mon petit echo bonjour fonctionne toujours avec
l'utilisateur lambda ;)
En attente de tester avec un user configuré depuis pool.d
Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur
lambda du serveur puisse interpréter PHP, dans /var/www/ cela me semble
étonnant, ou alors, je redécouvre que je n'ai rien compris à
l'interprétation de PHP par les utilisateurs de la machine.
On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un jour on a
appris qu'on a su et qu'on a oublié ...
