Serveur HTTP Apache Version 2.4
Description: | Sécurité de base (nécessaire) pour les plates-formes de la famille Unix. |
---|---|
Statut: | Base |
Identificateur de Module: | unixd_module |
Fichier Source: | mod_unixd.c |
Description: | Répertoire dans lequel Apache doit se positionner au démarrage après avoir effectué un chroot(8). |
---|---|
Syntaxe: | ChrootDir chemin-répertoire |
Défaut: | Non défini |
Contexte: | configuration globale |
Statut: | Base |
Module: | mod_unixd |
Compatibilité: | Disponible depuis la version 2.2.10 d'Apache |
Cette directive fait en sorte que le serveur effectue un chroot(8) vers le répertoire spécifié après le démarrage, mais avant d'accepter les requêtes en provenance du réseau.
Notez que l'exécution du serveur dans un environnement chroot n'est pas simple et nécessite une configuration particulière, en particulier si vous utilisez des scripts CGI ou PHP. Il est conseillé de se familiariser avec l'opération chroot avant d'essayer d'utiliser cette fonctionnalité.
Description: | Groupe sous lequel le serveur va traiter les requêtes |
---|---|
Syntaxe: | Group groupe unix |
Défaut: | Group #-1 |
Contexte: | configuration globale |
Statut: | Base |
Module: | mod_unixd |
La directive Group
permet de définir le
groupe sous lequel le serveur va traiter les requêtes. Pour
utiliser cette directive, le serveur doit avoir été démarré par
root
. Si vous démarrez le serveur en tant
qu'utilisateur non root, celui-ci ne pourra pas adopter le groupe
spécifié comme groupe d'exécution, et continuera à s'exécuter sous
le groupe de l'utilisateur qui l'aura lancé. groupe unix
peut se présenter sous la forme :
#
suivi d'un numéro de groupe.Group www-group
Il est conseillé de créer un groupe dédié à l'exécution du
serveur. Certains administrateurs utilisent l'utilisateur
nobody
, mais ce n'est pas toujours souhaitable ou même
possible.
Ne définissez pas la directive Group
(ou
User
) à
root
à moins de savoir exactement ce que vous faites
ainsi que les dangers encourus.
Description: | Active ou désactive la fonctionnalité suEXEC |
---|---|
Syntaxe: | Suexec On|Off |
Défaut: | On si le binaire suexec existe avec les mode et propriétaire
appropriés, Off dans le cas contraire |
Contexte: | configuration globale |
Statut: | Base |
Module: | mod_unixd |
Lorsque cette directive est définie à On, le démarrage échouera si le binaire suexec n'existe pas, ou possède un propriétaire ou mode fichier invalide.
Lorsque cette directive est définie à Off, suEXEC sera désactivé, même si le binaire suexec existe et possède un propriétaire et mode fichier valides.
Description: | L'utilisateur sous lequel le serveur va traiter les requêtes |
---|---|
Syntaxe: | User utilisateur unix |
Défaut: | User #-1 |
Contexte: | configuration globale |
Statut: | Base |
Module: | mod_unixd |
La directive User
permet de définir
l'utilisateur sous lequel le serveur va traiter les requêtes. Pour
utiliser cette directive, le serveur doit avoir été démarré
par root
. Si vous démarrez le serveur en tant
qu'utilisateur non root, celui-ci ne pourra pas adopter
l'utilisateur avec privilèges restreints comme utilisateur
d'exécution, et continuera à s'exécuter sous
l'utilisateur qui l'aura lancé. Si vous démarrez le serveur en tant
que root
, il est normal que le processus parent
continue à s'exécuter sous root. utilisateur unix peut se
présenter sous la forme :
L'utilisateur ne doit pas posséder de privilèges qui lui
permettraient d'accéder à des fichiers non destinés au
monde extérieur, et parallèlement, l'utilisateur ne doit pas
exécuter de code dont l'usage soit destiné à un usage autre que les
requêtes HTTP. Il est conseillé de créer un utilisateur et un groupe
dédiés à l'exécution du serveur. Certains administrateurs utilisent
l'utilisateur nobody
, mais ce n'est pas toujours
souhaitable, car l'utilisateur nobody
peut avoir
diverses utilisations dans le système.
Ne définissez pas la directive Group
(ou
User
) à
root
à moins de savoir exactement ce que vous faites
ainsi que les dangers encourus.