publish: Créer un groupe d'utilisateurs pour un site web Apache
This commit is contained in:
Cédrix
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"title": "Créer un groupe d'utilisateurs pour un site web Apache",
|
||||
"_updated_at": "2026-05-17 06:06:11",
|
||||
"slug": "creer-un-groupe-d-utilisateurs-pour-un-site-web",
|
||||
"published": true,
|
||||
"published_at": "2023-02-10 22:48",
|
||||
"category": "Informatique",
|
||||
"tags": [],
|
||||
"seo_title": "",
|
||||
"seo_description": ""
|
||||
}
|
||||
@@ -1,265 +0,0 @@
|
||||
# Créer un groupe d'utilisateurs pour un site web Apache
|
||||
|
||||
## Pourquoi un groupe par site ?
|
||||
|
||||
Quand on héberge un site web, deux populations doivent pouvoir lire ses fichiers : **Apache** (le serveur web, qui les sert aux visiteurs) et les **personnes qui maintiennent le site** (développeurs, intégrateurs, administrateurs de contenu). Si on ne réfléchit pas à la question des droits, on tombe rapidement dans un des deux travers classiques :
|
||||
|
||||
- **Tout ouvrir** (`chmod 777` partout) : c'est la porte ouverte aux compromissions. Si une faille permet à Apache d'écrire un fichier, l'attaquant peut alors écraser n'importe quel script PHP du site.
|
||||
- **Tout faire en root** : c'est pratique au début, mais cela impose à chaque mainteneur de connaître le mot de passe administrateur, et il devient impossible de tracer qui a modifié quoi.
|
||||
|
||||
La bonne pratique est donc de créer **un groupe dédié par site**, qui rassemble les personnes habilitées à intervenir dessus. Plusieurs avantages :
|
||||
|
||||
- **Évolutif** : ajouter ou retirer un mainteneur revient à ajouter ou retirer un utilisateur du groupe, sans rien changer aux permissions des fichiers.
|
||||
- **Étanche** : les mainteneurs d'un site n'ont aucun droit sur les autres sites de la machine.
|
||||
- **Traçable** : chaque modification est faite par un compte nommé, pas par `root`.
|
||||
|
||||
Cette approche reste valable même pour un site géré par une seule personne : le jour où vous voudrez déléguer la maintenance ou simplement créer un compte de déploiement, le travail aura déjà été fait.
|
||||
|
||||
Dans cet article, on prend comme exemple un site fictif **perdu.com**, dont les fichiers seront placés dans `/var/www/perdu.com`. Adaptez les noms à votre cas.
|
||||
|
||||
## Étape 1 — Créer le groupe dédié
|
||||
|
||||
```
|
||||
sudo groupadd www-perdu.com
|
||||
```
|
||||
|
||||
Le nom du groupe est arbitraire ; le préfixe `www-` est une convention qui rappelle qu'il s'agit d'un groupe lié à un site web. Vous pouvez vérifier sa création :
|
||||
|
||||
```
|
||||
getent group www-perdu.com
|
||||
```
|
||||
|
||||
## Étape 2 — Ajouter les mainteneurs au groupe
|
||||
|
||||
Ajoutez chaque utilisateur qui devra travailler sur le site :
|
||||
|
||||
```
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
```
|
||||
|
||||
L'option **`-a` (append) est obligatoire** : sans elle, `-G` **remplace** la liste complète des groupes secondaires de l'utilisateur au lieu d'y ajouter. C'est l'erreur classique qui fait perdre à quelqu'un l'accès à `sudo`, `docker` ou `libvirt` parce qu'on a écrasé ses autres appartenances.
|
||||
|
||||
Pour ajouter plusieurs personnes :
|
||||
|
||||
```
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
sudo usermod -aG www-perdu.com mathieu
|
||||
```
|
||||
|
||||
**Important** : l'appartenance à un nouveau groupe n'est prise en compte qu'à la **prochaine ouverture de session**. Si chloe est déjà connectée, elle doit se déconnecter puis se reconnecter (ou ouvrir un nouveau terminal SSH). Pour vérifier ses groupes effectifs :
|
||||
|
||||
```
|
||||
groups chloe
|
||||
```
|
||||
|
||||
## Étape 3 — Créer l'arborescence du site
|
||||
|
||||
On place le site dans `/var/www`, l'emplacement standard sur Debian/Ubuntu et un choix courant sur Fedora/RHEL :
|
||||
|
||||
```
|
||||
sudo mkdir -p /var/www/perdu.com/www
|
||||
sudo mkdir -p /var/www/perdu.com/logs
|
||||
```
|
||||
|
||||
L'option `-p` crée les dossiers parents au besoin et ne renvoie pas d'erreur s'ils existent déjà. La structure proposée sépare les fichiers servis publiquement (`www/`) de ce qui ne doit jamais être exposé (logs applicatifs, sauvegardes, données privées).
|
||||
|
||||
À ce stade, les dossiers appartiennent à `root:root` avec des droits `755`. Personne d'autre que root ne peut y écrire.
|
||||
|
||||
## Étape 4 — Attribuer la propriété au groupe
|
||||
|
||||
On veut que :
|
||||
|
||||
- **Le groupe `www-perdu.com`** puisse lire **et écrire** dans les dossiers (les mainteneurs déploient et modifient les fichiers).
|
||||
- **Apache** puisse lire les fichiers pour les servir.
|
||||
- **Personne d'autre** ne puisse y accéder.
|
||||
|
||||
On commence par attribuer le groupe :
|
||||
|
||||
```
|
||||
sudo chgrp -R www-perdu.com /var/www/perdu.com
|
||||
```
|
||||
|
||||
L'option `-R` (récursif) applique le changement à tout le contenu déjà présent.
|
||||
|
||||
Puis on applique des permissions adaptées :
|
||||
|
||||
```
|
||||
sudo find /var/www/perdu.com -type d -exec chmod 2775 {} \;
|
||||
sudo find /var/www/perdu.com -type f -exec chmod 664 {} \;
|
||||
```
|
||||
|
||||
Décortiquons ce qui se passe ici. On utilise `find` plutôt qu'un `chmod -R` unique parce que **les permissions des dossiers et des fichiers ne doivent pas être les mêmes** : un fichier de configuration n'a pas à être exécutable, alors qu'un dossier a besoin du bit `x` pour être parcouru.
|
||||
|
||||
- **Dossiers : `2775`** soit `rwxrwsr-x`. Le propriétaire (root) et les membres du groupe `www-perdu.com` peuvent lire, écrire et entrer dans le dossier. Les autres (dont `www-data`/`apache`) peuvent lire et entrer, mais pas modifier.
|
||||
- **Fichiers : `664`** soit `rw-rw-r--`. Le propriétaire et le groupe peuvent lire et écrire, les autres uniquement lire.
|
||||
|
||||
### Le bit SGID : pourquoi le `2` en tête ?
|
||||
|
||||
Le chiffre `2` devant `775` active le **bit SGID** sur les dossiers. Ce bit a un effet décisif : **tout nouveau fichier ou sous-dossier créé hérite automatiquement du groupe du dossier parent**, au lieu d'hériter du groupe principal de la personne qui le crée.
|
||||
|
||||
Sans SGID, si chloe (dont le groupe principal est `chloe`) crée un fichier, ce fichier appartient au groupe `chloe`, ce qui le rend invisible en écriture pour les autres mainteneurs du site. Avec SGID, le fichier appartient automatiquement à `www-perdu.com`, et toute l'équipe peut continuer à travailler dessus sans intervention.
|
||||
|
||||
Si vous préférez utiliser `chmod` directement plutôt que `find`, voici la version équivalente — un peu plus permissive sur les exécutables existants, mais plus simple à retenir :
|
||||
|
||||
```
|
||||
sudo chmod -R g+rwX,o+rX,o-w /var/www/perdu.com
|
||||
sudo find /var/www/perdu.com -type d -exec chmod g+s {} \;
|
||||
```
|
||||
|
||||
L'astuce du `X` majuscule (au lieu de `x` minuscule) est utile : elle n'ajoute le droit d'exécution qu'aux dossiers et aux fichiers déjà exécutables, sans rendre exécutables tous les fichiers texte par mégarde.
|
||||
|
||||
## Étape 5 — Garantir les bons droits sur les nouveaux fichiers
|
||||
|
||||
Le SGID s'occupe du groupe, mais pas des permissions elles-mêmes. Pour que les fichiers créés par un mainteneur soient en `664` (et non en `644` qui interdirait l'écriture aux autres membres du groupe), il faut un **umask permissif** côté utilisateur.
|
||||
|
||||
Demandez à chaque mainteneur d'ajouter cette ligne à son `~/.bashrc` :
|
||||
|
||||
```
|
||||
umask 0002
|
||||
```
|
||||
|
||||
Cet umask conserve les droits d'écriture pour le groupe. Avec un umask `0022` (le défaut habituel), chloe créerait des fichiers en `644` que mathieu ne pourrait pas modifier.
|
||||
|
||||
### Solution plus robuste : les ACL
|
||||
|
||||
Si vous voulez une garantie absolue sans dépendre du umask de chacun, les **ACL** (*Access Control Lists*) sont l'outil de référence :
|
||||
|
||||
```
|
||||
sudo setfacl -R -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
sudo setfacl -R -d -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
```
|
||||
|
||||
La première ligne applique le droit, la seconde le rend **par défaut** : tout nouveau fichier ou dossier créé dedans héritera automatiquement de ces droits, peu importe l'umask. Sur Debian/Ubuntu, les ACL sont déjà activées par défaut sur les systèmes de fichiers modernes ; sur d'autres distributions, vous pourriez devoir installer le paquet `acl`.
|
||||
|
||||
Vérifier les ACL en place :
|
||||
|
||||
```
|
||||
getfacl /var/www/perdu.com
|
||||
```
|
||||
|
||||
## Étape 6 — Le cas particulier d'Apache
|
||||
|
||||
Sur Debian/Ubuntu, Apache fonctionne sous l'utilisateur **`www-data`** ; sur Fedora/RHEL et openSUSE, il s'agit de **`apache`**. Vérifiez le bon nom sur votre système :
|
||||
|
||||
```
|
||||
ps aux | grep -E 'apache|httpd' | grep -v grep
|
||||
```
|
||||
|
||||
Avec les permissions définies plus haut, Apache peut **lire** tous les fichiers du site (le droit `r-x` accordé aux *autres* suffit). C'est ce qu'on veut dans 90 % des cas : Apache sert le contenu sans pouvoir le modifier, ce qui limite considérablement les dégâts d'une éventuelle faille.
|
||||
|
||||
### Quand Apache a besoin d'écrire
|
||||
|
||||
Certaines applications web ont besoin qu'Apache puisse écrire dans des dossiers précis : envoi de fichiers via un formulaire, cache, sessions, génération de miniatures… Le piège, c'est de répondre à ce besoin en ouvrant l'écriture **partout**, ce qui rend possible le téléversement d'un script malveillant qui sera ensuite exécuté.
|
||||
|
||||
**Ne donnez l'écriture à Apache que sur les dossiers strictement nécessaires.** Exemple pour un dossier `uploads` :
|
||||
|
||||
```
|
||||
sudo mkdir -p /var/www/perdu.com/www/uploads
|
||||
sudo chown www-data:www-perdu.com /var/www/perdu.com/www/uploads
|
||||
sudo chmod 2775 /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
Sur Fedora/RHEL, remplacez `www-data` par `apache`.
|
||||
|
||||
**Variante avec ACL**, sans changer le propriétaire :
|
||||
|
||||
```
|
||||
sudo setfacl -R -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
sudo setfacl -R -d -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
C'est souvent plus propre : le propriétaire principal reste `root`, et on ajoute juste un droit ciblé pour Apache. Pas d'ambiguïté sur « à qui appartient ce dossier ».
|
||||
|
||||
### Empêcher l'exécution dans les dossiers d'upload
|
||||
|
||||
Un dossier où Apache peut écrire et où il peut exécuter du PHP est une cible classique. Désactivez explicitement l'exécution de scripts dans `uploads/` via la configuration Apache du site :
|
||||
|
||||
```
|
||||
<Directory /var/www/perdu.com/www/uploads>
|
||||
php_admin_flag engine off
|
||||
<FilesMatch "\.(php|phtml|phar|cgi|pl|py|sh)$">
|
||||
Require all denied
|
||||
</FilesMatch>
|
||||
</Directory>
|
||||
```
|
||||
|
||||
## Étape 7 — Cas particulier de SELinux (Fedora, RHEL, AlmaLinux…)
|
||||
|
||||
Sur les distributions qui activent SELinux par défaut, des permissions Unix correctes **ne suffisent pas** : il faut aussi que les fichiers portent le bon contexte de sécurité. Si Apache renvoie des erreurs 403 alors que `ls -l` semble correct, c'est presque toujours SELinux.
|
||||
|
||||
Pour un dossier de contenu en lecture seule par Apache :
|
||||
|
||||
```
|
||||
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/perdu.com(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com
|
||||
```
|
||||
|
||||
Pour un dossier où Apache doit pouvoir écrire (comme `uploads`) :
|
||||
|
||||
```
|
||||
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/perdu.com/www/uploads(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
La commande `semanage` enregistre la règle de manière persistante (elle survit aux mises à jour), et `restorecon` l'applique aux fichiers existants. Sur Debian/Ubuntu, ces commandes ne sont pas nécessaires (SELinux n'y est pas activé par défaut, AppArmor joue un rôle équivalent mais ne demande généralement pas de configuration spécifique pour Apache).
|
||||
|
||||
## Vérification finale
|
||||
|
||||
Pour vérifier que tout est correct, listez les permissions :
|
||||
|
||||
```
|
||||
ls -ld /var/www/perdu.com
|
||||
ls -l /var/www/perdu.com/www
|
||||
```
|
||||
|
||||
Vous devriez voir quelque chose comme :
|
||||
|
||||
```
|
||||
drwxrwsr-x 3 root www-perdu.com 4096 Mar 12 14:00 /var/www/perdu.com
|
||||
drwxrwsr-x 2 root www-perdu.com 4096 Mar 12 14:00 /var/www/perdu.com/www
|
||||
```
|
||||
|
||||
Notez le `s` dans `rws` à la place du `x` du groupe : c'est la signature visuelle du bit SGID. C'est le signe que la configuration héritera correctement.
|
||||
|
||||
Créez un fichier de test en tant que chloe pour valider :
|
||||
|
||||
```
|
||||
su - chloe
|
||||
cd /var/www/perdu.com/www
|
||||
echo "<h1>Bienvenue</h1>" > index.html
|
||||
ls -l index.html
|
||||
```
|
||||
|
||||
Le fichier `index.html` doit appartenir à `chloe:www-perdu.com` et être en `-rw-rw-r--` (mode 664). Si c'est le cas, vous êtes prêt à configurer le `VirtualHost` Apache pointant vers `/var/www/perdu.com/www`.
|
||||
|
||||
## En résumé
|
||||
|
||||
La recette complète, condensée :
|
||||
|
||||
```
|
||||
# 1. Créer le groupe et y ajouter les mainteneurs
|
||||
sudo groupadd www-perdu.com
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
|
||||
# 2. Créer l'arborescence
|
||||
sudo mkdir -p /var/www/perdu.com/www
|
||||
|
||||
# 3. Attribuer propriété et permissions avec SGID
|
||||
sudo chgrp -R www-perdu.com /var/www/perdu.com
|
||||
sudo find /var/www/perdu.com -type d -exec chmod 2775 {} \;
|
||||
sudo find /var/www/perdu.com -type f -exec chmod 664 {} \;
|
||||
|
||||
# 4. (Optionnel mais recommandé) Garantir l'héritage avec des ACL
|
||||
sudo setfacl -R -d -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
|
||||
# 5. Donner l'écriture à Apache UNIQUEMENT là où c'est nécessaire
|
||||
sudo setfacl -R -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
sudo setfacl -R -d -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
|
||||
# 6. Sur les systèmes SELinux, ajuster les contextes
|
||||
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/perdu.com(/.*)?"
|
||||
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/perdu.com/www/uploads(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com
|
||||
```
|
||||
|
||||
Le principe directeur à retenir : **un groupe par site, l'écriture pour les mainteneurs, la lecture pour Apache, et l'écriture pour Apache uniquement là où l'application en a strictement besoin**. C'est la base d'un hébergement multi-sites propre, durable et raisonnablement sûr.
|
||||
@@ -1,47 +1,265 @@
|
||||
# Créer un groupe d'utilisateurs pour un site Web
|
||||
# Créer un groupe d'utilisateurs pour un site web Apache
|
||||
|
||||
<note tip>Cet article fait partie de la collection </note>
|
||||
## Pourquoi un groupe par site ?
|
||||
|
||||
Avant de créer un site dans la configuration Apache 2, vous devez déterminer un groupe d'utilisateurs (administrateurs, développeurs, opérateurs...) qui devront accéder aux fichiers du site.
|
||||
Quand on héberge un site web, deux populations doivent pouvoir lire ses fichiers : **Apache** (le serveur web, qui les sert aux visiteurs) et les **personnes qui maintiennent le site** (développeurs, intégrateurs, administrateurs de contenu). Si on ne réfléchit pas à la question des droits, on tombe rapidement dans un des deux travers classiques :
|
||||
|
||||
Le bonne pratique est de créer un groupe d'utilisateur qui sera en charge du maintient du site web. Même pour un seul utilisateur cette méthode est valable et <u>évolutive</u>. Il est vivement conseillé de créer <u>un groupe par site Internet</u>.
|
||||
- **Tout ouvrir** (`chmod 777` partout) : c'est la porte ouverte aux compromissions. Si une faille permet à Apache d'écrire un fichier, l'attaquant peut alors écraser n'importe quel script PHP du site.
|
||||
- **Tout faire en root** : c'est pratique au début, mais cela impose à chaque mainteneur de connaître le mot de passe administrateur, et il devient impossible de tracer qui a modifié quoi.
|
||||
|
||||
La bonne pratique est donc de créer **un groupe dédié par site**, qui rassemble les personnes habilitées à intervenir dessus. Plusieurs avantages :
|
||||
|
||||
- **Évolutif** : ajouter ou retirer un mainteneur revient à ajouter ou retirer un utilisateur du groupe, sans rien changer aux permissions des fichiers.
|
||||
- **Étanche** : les mainteneurs d'un site n'ont aucun droit sur les autres sites de la machine.
|
||||
- **Traçable** : chaque modification est faite par un compte nommé, pas par `root`.
|
||||
|
||||
Cette approche reste valable même pour un site géré par une seule personne : le jour où vous voudrez déléguer la maintenance ou simplement créer un compte de déploiement, le travail aura déjà été fait.
|
||||
|
||||
Dans cet article, on prend comme exemple un site fictif **perdu.com**, dont les fichiers seront placés dans `/var/www/perdu.com`. Adaptez les noms à votre cas.
|
||||
|
||||
## Étape 1 — Créer le groupe dédié
|
||||
|
||||
## Créer un groupe
|
||||
```
|
||||
sudo groupadd www-perdu.com
|
||||
```
|
||||
|
||||
## Associer l'utilisateur au groupe
|
||||
Le nom du groupe est arbitraire ; le préfixe `www-` est une convention qui rappelle qu'il s'agit d'un groupe lié à un site web. Vous pouvez vérifier sa création :
|
||||
|
||||
```
|
||||
sudo usermod -a -G www-perdu.com chloe
|
||||
getent group www-perdu.com
|
||||
```
|
||||
|
||||
Si vous êtes logué avec le compte `chloe`, il faut se déconnecter et connecter pour que `usermod` soit pris en compte.
|
||||
## Étape 2 — Ajouter les mainteneurs au groupe
|
||||
|
||||
## Créer les dossiers du site
|
||||
Je vais créer le dossier du site dans `/var/www`. Les droits seront automatiquement donnés à `root` afin d'empêcher n'importe qui d'aller modifier le contenu.
|
||||
Ajoutez chaque utilisateur qui devra travailler sur le site :
|
||||
|
||||
```
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
```
|
||||
|
||||
L'option **`-a` (append) est obligatoire** : sans elle, `-G` **remplace** la liste complète des groupes secondaires de l'utilisateur au lieu d'y ajouter. C'est l'erreur classique qui fait perdre à quelqu'un l'accès à `sudo`, `docker` ou `libvirt` parce qu'on a écrasé ses autres appartenances.
|
||||
|
||||
Pour ajouter plusieurs personnes :
|
||||
|
||||
```
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
sudo usermod -aG www-perdu.com mathieu
|
||||
```
|
||||
|
||||
**Important** : l'appartenance à un nouveau groupe n'est prise en compte qu'à la **prochaine ouverture de session**. Si chloe est déjà connectée, elle doit se déconnecter puis se reconnecter (ou ouvrir un nouveau terminal SSH). Pour vérifier ses groupes effectifs :
|
||||
|
||||
```
|
||||
groups chloe
|
||||
```
|
||||
|
||||
## Étape 3 — Créer l'arborescence du site
|
||||
|
||||
On place le site dans `/var/www`, l'emplacement standard sur Debian/Ubuntu et un choix courant sur Fedora/RHEL :
|
||||
|
||||
```
|
||||
sudo mkdir -p /var/www/perdu.com/www
|
||||
sudo chown -R root /var/www/perdu.com
|
||||
sudo mkdir -p /var/www/perdu.com/logs
|
||||
```
|
||||
|
||||
## Modifier le groupe des dossiers du site
|
||||
L'objectif est de données les droits au groupe `www-perdu.com` et de restreindre l'accès en lecture seule aux autres groupes d'utilisateurs.
|
||||
L'option `-p` crée les dossiers parents au besoin et ne renvoie pas d'erreur s'ils existent déjà. La structure proposée sépare les fichiers servis publiquement (`www/`) de ce qui ne doit jamais être exposé (logs applicatifs, sauvegardes, données privées).
|
||||
|
||||
À ce stade, les dossiers appartiennent à `root:root` avec des droits `755`. Personne d'autre que root ne peut y écrire.
|
||||
|
||||
## Étape 4 — Attribuer la propriété au groupe
|
||||
|
||||
On veut que :
|
||||
|
||||
- **Le groupe `www-perdu.com`** puisse lire **et écrire** dans les dossiers (les mainteneurs déploient et modifient les fichiers).
|
||||
- **Apache** puisse lire les fichiers pour les servir.
|
||||
- **Personne d'autre** ne puisse y accéder.
|
||||
|
||||
On commence par attribuer le groupe :
|
||||
|
||||
```
|
||||
sudo chgrp -R www-perdu.com /var/www/perdu.com
|
||||
sudo chmod -R 775 /var/www/perdu.com
|
||||
```
|
||||
|
||||
Lorsque qu'un fichier est créé, afin de garder la priorité au groupe de développeurs, j'attribue l'option `s`
|
||||
L'option `-R` (récursif) applique le changement à tout le contenu déjà présent.
|
||||
|
||||
Puis on applique des permissions adaptées :
|
||||
|
||||
```
|
||||
sudo chmod -R g+s /var/www/perdu.com
|
||||
sudo find /var/www/perdu.com -type d -exec chmod 2775 {} \;
|
||||
sudo find /var/www/perdu.com -type f -exec chmod 664 {} \;
|
||||
```
|
||||
|
||||
S'il est nécessaire d'autoriser Apache à modifier le contenu d'un dossier, par exemple `uploads`, je modifierai les droits en attribuant le groupe à `www-data` (groupe d'utilisation d'Apache 2).
|
||||
|
||||
Décortiquons ce qui se passe ici. On utilise `find` plutôt qu'un `chmod -R` unique parce que **les permissions des dossiers et des fichiers ne doivent pas être les mêmes** : un fichier de configuration n'a pas à être exécutable, alors qu'un dossier a besoin du bit `x` pour être parcouru.
|
||||
|
||||
- **Dossiers : `2775`** soit `rwxrwsr-x`. Le propriétaire (root) et les membres du groupe `www-perdu.com` peuvent lire, écrire et entrer dans le dossier. Les autres (dont `www-data`/`apache`) peuvent lire et entrer, mais pas modifier.
|
||||
- **Fichiers : `664`** soit `rw-rw-r--`. Le propriétaire et le groupe peuvent lire et écrire, les autres uniquement lire.
|
||||
|
||||
### Le bit SGID : pourquoi le `2` en tête ?
|
||||
|
||||
Le chiffre `2` devant `775` active le **bit SGID** sur les dossiers. Ce bit a un effet décisif : **tout nouveau fichier ou sous-dossier créé hérite automatiquement du groupe du dossier parent**, au lieu d'hériter du groupe principal de la personne qui le crée.
|
||||
|
||||
Sans SGID, si chloe (dont le groupe principal est `chloe`) crée un fichier, ce fichier appartient au groupe `chloe`, ce qui le rend invisible en écriture pour les autres mainteneurs du site. Avec SGID, le fichier appartient automatiquement à `www-perdu.com`, et toute l'équipe peut continuer à travailler dessus sans intervention.
|
||||
|
||||
Si vous préférez utiliser `chmod` directement plutôt que `find`, voici la version équivalente — un peu plus permissive sur les exécutables existants, mais plus simple à retenir :
|
||||
|
||||
```
|
||||
sudo chown -R www-data /var/www/perdu.com/www/uploads
|
||||
```
|
||||
sudo chmod -R g+rwX,o+rX,o-w /var/www/perdu.com
|
||||
sudo find /var/www/perdu.com -type d -exec chmod g+s {} \;
|
||||
```
|
||||
|
||||
L'astuce du `X` majuscule (au lieu de `x` minuscule) est utile : elle n'ajoute le droit d'exécution qu'aux dossiers et aux fichiers déjà exécutables, sans rendre exécutables tous les fichiers texte par mégarde.
|
||||
|
||||
## Étape 5 — Garantir les bons droits sur les nouveaux fichiers
|
||||
|
||||
Le SGID s'occupe du groupe, mais pas des permissions elles-mêmes. Pour que les fichiers créés par un mainteneur soient en `664` (et non en `644` qui interdirait l'écriture aux autres membres du groupe), il faut un **umask permissif** côté utilisateur.
|
||||
|
||||
Demandez à chaque mainteneur d'ajouter cette ligne à son `~/.bashrc` :
|
||||
|
||||
```
|
||||
umask 0002
|
||||
```
|
||||
|
||||
Cet umask conserve les droits d'écriture pour le groupe. Avec un umask `0022` (le défaut habituel), chloe créerait des fichiers en `644` que mathieu ne pourrait pas modifier.
|
||||
|
||||
### Solution plus robuste : les ACL
|
||||
|
||||
Si vous voulez une garantie absolue sans dépendre du umask de chacun, les **ACL** (*Access Control Lists*) sont l'outil de référence :
|
||||
|
||||
```
|
||||
sudo setfacl -R -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
sudo setfacl -R -d -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
```
|
||||
|
||||
La première ligne applique le droit, la seconde le rend **par défaut** : tout nouveau fichier ou dossier créé dedans héritera automatiquement de ces droits, peu importe l'umask. Sur Debian/Ubuntu, les ACL sont déjà activées par défaut sur les systèmes de fichiers modernes ; sur d'autres distributions, vous pourriez devoir installer le paquet `acl`.
|
||||
|
||||
Vérifier les ACL en place :
|
||||
|
||||
```
|
||||
getfacl /var/www/perdu.com
|
||||
```
|
||||
|
||||
## Étape 6 — Le cas particulier d'Apache
|
||||
|
||||
Sur Debian/Ubuntu, Apache fonctionne sous l'utilisateur **`www-data`** ; sur Fedora/RHEL et openSUSE, il s'agit de **`apache`**. Vérifiez le bon nom sur votre système :
|
||||
|
||||
```
|
||||
ps aux | grep -E 'apache|httpd' | grep -v grep
|
||||
```
|
||||
|
||||
Avec les permissions définies plus haut, Apache peut **lire** tous les fichiers du site (le droit `r-x` accordé aux *autres* suffit). C'est ce qu'on veut dans 90 % des cas : Apache sert le contenu sans pouvoir le modifier, ce qui limite considérablement les dégâts d'une éventuelle faille.
|
||||
|
||||
### Quand Apache a besoin d'écrire
|
||||
|
||||
Certaines applications web ont besoin qu'Apache puisse écrire dans des dossiers précis : envoi de fichiers via un formulaire, cache, sessions, génération de miniatures… Le piège, c'est de répondre à ce besoin en ouvrant l'écriture **partout**, ce qui rend possible le téléversement d'un script malveillant qui sera ensuite exécuté.
|
||||
|
||||
**Ne donnez l'écriture à Apache que sur les dossiers strictement nécessaires.** Exemple pour un dossier `uploads` :
|
||||
|
||||
```
|
||||
sudo mkdir -p /var/www/perdu.com/www/uploads
|
||||
sudo chown www-data:www-perdu.com /var/www/perdu.com/www/uploads
|
||||
sudo chmod 2775 /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
Sur Fedora/RHEL, remplacez `www-data` par `apache`.
|
||||
|
||||
**Variante avec ACL**, sans changer le propriétaire :
|
||||
|
||||
```
|
||||
sudo setfacl -R -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
sudo setfacl -R -d -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
C'est souvent plus propre : le propriétaire principal reste `root`, et on ajoute juste un droit ciblé pour Apache. Pas d'ambiguïté sur « à qui appartient ce dossier ».
|
||||
|
||||
### Empêcher l'exécution dans les dossiers d'upload
|
||||
|
||||
Un dossier où Apache peut écrire et où il peut exécuter du PHP est une cible classique. Désactivez explicitement l'exécution de scripts dans `uploads/` via la configuration Apache du site :
|
||||
|
||||
```
|
||||
<Directory /var/www/perdu.com/www/uploads>
|
||||
php_admin_flag engine off
|
||||
<FilesMatch "\.(php|phtml|phar|cgi|pl|py|sh)$">
|
||||
Require all denied
|
||||
</FilesMatch>
|
||||
</Directory>
|
||||
```
|
||||
|
||||
## Étape 7 — Cas particulier de SELinux (Fedora, RHEL, AlmaLinux…)
|
||||
|
||||
Sur les distributions qui activent SELinux par défaut, des permissions Unix correctes **ne suffisent pas** : il faut aussi que les fichiers portent le bon contexte de sécurité. Si Apache renvoie des erreurs 403 alors que `ls -l` semble correct, c'est presque toujours SELinux.
|
||||
|
||||
Pour un dossier de contenu en lecture seule par Apache :
|
||||
|
||||
```
|
||||
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/perdu.com(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com
|
||||
```
|
||||
|
||||
Pour un dossier où Apache doit pouvoir écrire (comme `uploads`) :
|
||||
|
||||
```
|
||||
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/perdu.com/www/uploads(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com/www/uploads
|
||||
```
|
||||
|
||||
La commande `semanage` enregistre la règle de manière persistante (elle survit aux mises à jour), et `restorecon` l'applique aux fichiers existants. Sur Debian/Ubuntu, ces commandes ne sont pas nécessaires (SELinux n'y est pas activé par défaut, AppArmor joue un rôle équivalent mais ne demande généralement pas de configuration spécifique pour Apache).
|
||||
|
||||
## Vérification finale
|
||||
|
||||
Pour vérifier que tout est correct, listez les permissions :
|
||||
|
||||
```
|
||||
ls -ld /var/www/perdu.com
|
||||
ls -l /var/www/perdu.com/www
|
||||
```
|
||||
|
||||
Vous devriez voir quelque chose comme :
|
||||
|
||||
```
|
||||
drwxrwsr-x 3 root www-perdu.com 4096 Mar 12 14:00 /var/www/perdu.com
|
||||
drwxrwsr-x 2 root www-perdu.com 4096 Mar 12 14:00 /var/www/perdu.com/www
|
||||
```
|
||||
|
||||
Notez le `s` dans `rws` à la place du `x` du groupe : c'est la signature visuelle du bit SGID. C'est le signe que la configuration héritera correctement.
|
||||
|
||||
Créez un fichier de test en tant que chloe pour valider :
|
||||
|
||||
```
|
||||
su - chloe
|
||||
cd /var/www/perdu.com/www
|
||||
echo "<h1>Bienvenue</h1>" > index.html
|
||||
ls -l index.html
|
||||
```
|
||||
|
||||
Le fichier `index.html` doit appartenir à `chloe:www-perdu.com` et être en `-rw-rw-r--` (mode 664). Si c'est le cas, vous êtes prêt à configurer le `VirtualHost` Apache pointant vers `/var/www/perdu.com/www`.
|
||||
|
||||
## En résumé
|
||||
|
||||
La recette complète, condensée :
|
||||
|
||||
```
|
||||
# 1. Créer le groupe et y ajouter les mainteneurs
|
||||
sudo groupadd www-perdu.com
|
||||
sudo usermod -aG www-perdu.com chloe
|
||||
|
||||
# 2. Créer l'arborescence
|
||||
sudo mkdir -p /var/www/perdu.com/www
|
||||
|
||||
# 3. Attribuer propriété et permissions avec SGID
|
||||
sudo chgrp -R www-perdu.com /var/www/perdu.com
|
||||
sudo find /var/www/perdu.com -type d -exec chmod 2775 {} \;
|
||||
sudo find /var/www/perdu.com -type f -exec chmod 664 {} \;
|
||||
|
||||
# 4. (Optionnel mais recommandé) Garantir l'héritage avec des ACL
|
||||
sudo setfacl -R -d -m g:www-perdu.com:rwX /var/www/perdu.com
|
||||
|
||||
# 5. Donner l'écriture à Apache UNIQUEMENT là où c'est nécessaire
|
||||
sudo setfacl -R -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
sudo setfacl -R -d -m u:www-data:rwX /var/www/perdu.com/www/uploads
|
||||
|
||||
# 6. Sur les systèmes SELinux, ajuster les contextes
|
||||
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/perdu.com(/.*)?"
|
||||
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/perdu.com/www/uploads(/.*)?"
|
||||
sudo restorecon -Rv /var/www/perdu.com
|
||||
```
|
||||
|
||||
Le principe directeur à retenir : **un groupe par site, l'écriture pour les mainteneurs, la lecture pour Apache, et l'écriture pour Apache uniquement là où l'application en a strictement besoin**. C'est la base d'un hébergement multi-sites propre, durable et raisonnablement sûr.
|
||||
@@ -1,18 +1,27 @@
|
||||
{
|
||||
"uuid": "ab5f47cd-33f9-4e54-8e0f-c7389695fb78",
|
||||
"slug": "creer-un-groupe-d-utilisateurs-pour-un-site-web",
|
||||
"title": "Créer un groupe d'utilisateurs pour un site Web",
|
||||
"title": "Créer un groupe d'utilisateurs pour un site web Apache",
|
||||
"author": "cedric@abonnel.fr",
|
||||
"published": true,
|
||||
"published_at": "2023-02-10 22:48:33",
|
||||
"featured": false,
|
||||
"published_at": "2023-02-10 22:48",
|
||||
"created_at": "2023-02-10 22:48:33",
|
||||
"updated_at": "2023-02-10 22:48:33",
|
||||
"revisions": [],
|
||||
"updated_at": "2026-05-17 06:06:14",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
"date": "2026-05-17 06:06:14",
|
||||
"comment": "Titre modifié, contenu modifié",
|
||||
"title": "Créer un groupe d'utilisateurs pour un site Web"
|
||||
}
|
||||
],
|
||||
"cover": "",
|
||||
"files_meta": [],
|
||||
"external_links": [],
|
||||
"seo_title": "",
|
||||
"seo_description": "",
|
||||
"og_image": "",
|
||||
"category": "Informatique"
|
||||
"category": "Informatique",
|
||||
"tags": []
|
||||
}
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
# Créer un groupe d'utilisateurs pour un site Web
|
||||
|
||||
<note tip>Cet article fait partie de la collection </note>
|
||||
|
||||
Avant de créer un site dans la configuration Apache 2, vous devez déterminer un groupe d'utilisateurs (administrateurs, développeurs, opérateurs...) qui devront accéder aux fichiers du site.
|
||||
|
||||
Le bonne pratique est de créer un groupe d'utilisateur qui sera en charge du maintient du site web. Même pour un seul utilisateur cette méthode est valable et <u>évolutive</u>. Il est vivement conseillé de créer <u>un groupe par site Internet</u>.
|
||||
|
||||
## Créer un groupe
|
||||
```
|
||||
sudo groupadd www-perdu.com
|
||||
```
|
||||
|
||||
## Associer l'utilisateur au groupe
|
||||
```
|
||||
sudo usermod -a -G www-perdu.com chloe
|
||||
```
|
||||
|
||||
Si vous êtes logué avec le compte `chloe`, il faut se déconnecter et connecter pour que `usermod` soit pris en compte.
|
||||
|
||||
## Créer les dossiers du site
|
||||
Je vais créer le dossier du site dans `/var/www`. Les droits seront automatiquement donnés à `root` afin d'empêcher n'importe qui d'aller modifier le contenu.
|
||||
|
||||
```
|
||||
sudo mkdir -p /var/www/perdu.com/www
|
||||
sudo chown -R root /var/www/perdu.com
|
||||
```
|
||||
|
||||
## Modifier le groupe des dossiers du site
|
||||
L'objectif est de données les droits au groupe `www-perdu.com` et de restreindre l'accès en lecture seule aux autres groupes d'utilisateurs.
|
||||
|
||||
```
|
||||
sudo chgrp -R www-perdu.com /var/www/perdu.com
|
||||
sudo chmod -R 775 /var/www/perdu.com
|
||||
```
|
||||
|
||||
Lorsque qu'un fichier est créé, afin de garder la priorité au groupe de développeurs, j'attribue l'option `s`
|
||||
|
||||
```
|
||||
sudo chmod -R g+s /var/www/perdu.com
|
||||
```
|
||||
|
||||
S'il est nécessaire d'autoriser Apache à modifier le contenu d'un dossier, par exemple `uploads`, je modifierai les droits en attribuant le groupe à `www-data` (groupe d'utilisation d'Apache 2).
|
||||
|
||||
```
|
||||
sudo chown -R www-data /var/www/perdu.com/www/uploads
|
||||
```
|
||||
Reference in New Issue
Block a user