Evolution #1327
fermé
Pertinence du paramètre apacheuser
100%
Au lancement WSH contrôle que l'UID sous lequel il est exécuté est différent de 0 et égal à celui du propriétaire du fichier wsh.php.
Dans le code, toute occurrence de apacheuser est supprimée.
Description
Est-ce que le paramètre apacheuser est toujours pertinent et nécessaire ? Puisque actuellement toutes les tâches d'administration tournent sous Apache et que le reste doit se faire via le CLI WIFF qui tourne aussi sous l'identité du serveur Apache.
Est-ce qu'il y a un cas ou il est nécessaire d'avoir l'uid du process Apache codé en dur ? Actuellement c'est utilisé par des chown() dans API/vault_init.php et Class.VaultDiskDir.php, mais de toutes façons quand on s'exécute sous Apache, on ne peut pas faire de chown vers une autre identité que celle d'Apache.
Mis à jour par Éric Brison il y a plus de 15 ans
- Assigné à mis à Jérôme Augé
- Version cible mis à 3.(next-release-major)
Mis à jour par Marc Claverie il y a plus de 10 ans
- Version cible changé de 3.(next-release-major) à 3.2.21
- Version source mis à 3.2.20
- Thème Socle technique ajouté
Mis à jour par Éric Brison il y a plus de 10 ans
Le cas où il est nécessaire est le cas, où des wsh sont lancés sou l'identité "root".
Si on veut enlever ce paramétrage, il faut contrôler l'usage du wsh pour vérifier que c'est bien l'utilisateur d'apache (pas sûr que ce soit facile à faire).
Mis à jour par Jérôme Augé il y a plus de 10 ans
Personnellement je déconseille toujours de lancer "wsh.php" directement en root et de passer systématiquement par le CLI wiff (e.g. "wiff context ... exec ./wsh.php ...") qui baisse ses privilèges en passant sous l'uid Apache.
Le problème avec l'exécution en tant que root est que des fichiers peuvent être créés et il le seront avec root comme propriétaire et les droits hérités par son umask, etc. et cela rend ces fichiers soit non visibles par Apache soit non modifiables par Apache, ce qui peut poser problème par le suite lors du fonctionnement de Dynacase ou de prochaines mise à jour.
De plus, cela rend l'exécution de "wsh.php" dangereuse car le code PHP alors exécuté sous l'uid root qui a accès à tout le système : si du code malveillant est présent, la machine entière peut être compromise versus seulement les fichiers accessible à Apache dans le cas d'une exécution sous l'uid Apache (à condition là aussi qu'il n'y ait pas de faille d'élévation de privilège local sur la machine).
Je suis donc pour que "wsh.php" remonte une erreur et ne démarre pas s'il s'exécute sous root.
Cependant, ce paramètre "apacheuser" reste problématique par exemple lors de la restauration sur Ubuntu d'un contexte provenant d'une CentOS, le apacheuser du contexte reste avec sa valeur "apache" de CentOS qui n'existe pas sur Ubuntu.
Mis à jour par Marc Claverie il y a plus de 10 ans
- Statut changé de Nouveau à Assigné
- Solution proposée mis à jour (diff)
Mis à jour par Éric Brison il y a plus de 10 ans
- Statut changé de Assigné à Intégré
Appliqué par commit dynacase-core|commit:425a5b5288a902b48ea3348c74f9732e9c5d8d73.