add: Le bit SGID : faire collaborer plusieurs utilisateurs sur des fichiers partagés

4d4a4d2b-3380-4675-abb0-e50f29028dc6/index.md

@@ -0,0 +1,213 @@
+# Le bit SGID : faire collaborer plusieurs utilisateurs sur des fichiers partagés
+
+## Le problème que SGID résout
+
+Imaginez la situation suivante. Vous administrez un serveur où Alice et Bob doivent travailler ensemble sur un site web stocké dans `/var/www/site`. Vous avez bien fait les choses : créé un groupe `web-equipe`, ajouté Alice et Bob dedans, et donné les droits d'écriture au groupe sur le dossier.
+
+Alice crée un fichier `index.html`. Vous regardez les permissions :
+
+```
+-rw-rw-r-- 1 alice alice 240 mars 12 14:00 index.html
+```
+
+Patatras. Le fichier appartient au groupe `alice` (le groupe principal d'Alice), **pas** au groupe `web-equipe`. Conséquence : Bob, qui appartient à `web-equipe` mais pas à `alice`, **ne peut pas modifier ce fichier**. Chaque nouveau fichier reproduit le problème, et vous voilà à corriger les permissions à la main toute la journée.
+
+Le **bit SGID** (*Set Group ID*) est précisément la solution à ce problème, à l'échelle des dossiers : il force tout nouveau fichier ou sous-dossier à hériter du groupe de son dossier parent, au lieu du groupe principal de la personne qui l'a créé.
+
+## Le comportement par défaut sans SGID
+
+Quand un utilisateur crée un fichier sous Linux, le système applique deux règles :
+
+1. **Le propriétaire** du fichier est l'utilisateur qui le crée.
+2. **Le groupe** du fichier est son groupe principal (celui défini dans `/etc/passwd`).
+
+Ce comportement convient pour les fichiers personnels, mais pose problème dès qu'on veut un dossier partagé. Le groupe principal d'Alice est rarement celui qu'on souhaite voir attribué aux fichiers d'un projet collectif.
+
+## Activer SGID sur un dossier
+
+On utilise `chmod` avec le symbole `g+s` :
+
+```
+sudo chmod g+s /var/www/site
+```
+
+Ou en notation octale, en ajoutant un `2` devant les permissions classiques :
+
+```
+sudo chmod 2775 /var/www/site
+```
+
+Le `2` représente le bit SGID, exactement comme le `4` représenterait SUID et le `1` représenterait le sticky bit. Les valeurs courantes :
+
+- `2775` : SGID + `rwxrwxr-x` (groupe peut écrire, autres en lecture seule).
+- `2770` : SGID + `rwxrwx---` (rien pour les autres, dossier privé au groupe).
+- `2755` : SGID + `rwxr-xr-x` (lecture pour le groupe, dossier essentiellement public).
+
+## Reconnaître SGID dans la sortie de `ls -l`
+
+Quand SGID est actif, le `x` du groupe est remplacé par un `s` dans la sortie de `ls -l` :
+
+```
+drwxrwsr-x 2 root web-equipe 4096 mars 12 14:00 /var/www/site
+```
+
+Le `s` dans `rws` est la signature visuelle. Notez que :
+
+- Un `s` **minuscule** signifie : SGID actif **et** droit d'exécution actif pour le groupe (le cas normal sur un dossier).
+- Un `S` **majuscule** signifie : SGID actif **mais** droit d'exécution absent. C'est généralement une erreur de configuration sur un dossier — sans `x`, le groupe ne peut même pas y entrer.
+
+## Démonstration concrète
+
+Reprenons l'exemple d'Alice et Bob :
+
+```
+# Préparation
+sudo groupadd web-equipe
+sudo usermod -aG web-equipe alice
+sudo usermod -aG web-equipe bob
+sudo mkdir /var/www/site
+sudo chgrp web-equipe /var/www/site
+sudo chmod 2775 /var/www/site
+```
+
+Alice se reconnecte (pour que sa nouvelle appartenance au groupe soit effective) et crée un fichier :
+
+```
+alice@machine:~$ cd /var/www/site
+alice@machine:/var/www/site$ echo "Bonjour" > index.html
+alice@machine:/var/www/site$ ls -l index.html
+-rw-rw-r-- 1 alice web-equipe 8 mars 12 14:05 index.html
+```
+
+Cette fois, le fichier appartient au groupe `web-equipe`, pas au groupe `alice`. Bob peut maintenant le modifier sans intervention de l'administrateur. Le même mécanisme s'applique aux sous-dossiers : si Alice crée un sous-dossier `images/`, celui-ci appartient à `web-equipe` **et hérite à son tour du bit SGID**, ce qui propage le comportement à toute la hiérarchie.
+
+## Le compagnon indispensable : umask
+
+SGID gère le **groupe** du fichier, mais pas ses **permissions**. Si Alice a un umask de `0022` (le défaut sur la plupart des distributions), son fichier sera créé en `644` (rw-r--r--) : Bob, bien que membre du groupe propriétaire, ne pourra que le lire.
+
+Pour que SGID prenne tout son sens dans un contexte collaboratif, il faut un **umask plus permissif** côté utilisateur. La valeur classique est `0002`, qui produit des fichiers en `664` (rw-rw-r--) et des dossiers en `775`.
+
+Pour appliquer cet umask uniquement aux membres d'un groupe, on peut ajouter un test dans `/etc/profile.d/` :
+
+```
+sudo tee /etc/profile.d/umask-collaboratif.sh > /dev/null <<'EOF'
+if id -nG | grep -qw web-equipe; then
+    umask 0002
+fi
+EOF
+```
+
+Ou, plus simplement, chaque membre du groupe ajoute `umask 0002` dans son `~/.bashrc`.
+
+## Cas d'usage typiques
+
+### Hébergement web mutualisé
+
+C'est l'exemple développé plus haut. Un groupe par site, SGID sur le dossier racine, et l'équipe peut collaborer sans que personne ait à passer en `root`.
+
+### Partage familial sur un NAS
+
+Sur un serveur de fichiers à la maison :
+
+```
+sudo groupadd famille
+sudo usermod -aG famille alice
+sudo usermod -aG famille bob
+sudo mkdir /srv/famille
+sudo chgrp famille /srv/famille
+sudo chmod 2770 /srv/famille
+```
+
+Tout fichier déposé par Alice ou Bob dans `/srv/famille` appartiendra automatiquement au groupe `famille`, et l'autre pourra le modifier.
+
+### Dossier de dépôt pour un projet
+
+Une équipe de développement partage un dossier `/opt/projets/monapp/`. Tous les développeurs peuvent y déposer du code, et chacun peut reprendre le travail de l'autre.
+
+## SGID sur les fichiers exécutables : un usage différent (et plus rare)
+
+Le bit SGID a un sens complètement différent quand on l'applique à un **fichier exécutable** : il fait tourner le programme avec les **privilèges du groupe propriétaire du fichier**, et non avec ceux de la personne qui le lance.
+
+C'est le pendant « groupe » du bit SUID, qui lui élève les privilèges au niveau de l'utilisateur propriétaire (c'est ainsi que `passwd` peut modifier `/etc/shadow` même quand un utilisateur normal le lance).
+
+Un exemple historique est la commande `wall` (qui diffuse un message à toutes les sessions ouvertes) :
+
+```
+$ ls -l /usr/bin/wall
+-rwxr-sr-x 1 root tty 35304 mars 12 2024 /usr/bin/wall
+```
+
+Le `s` au niveau du groupe `tty` permet à `wall` d'écrire sur les terminaux de tous les utilisateurs, ce qu'un programme non privilégié ne pourrait pas faire.
+
+**Cette utilisation de SGID sur des exécutables est sensible** : un programme SGID mal écrit peut donner à un utilisateur quelconque un accès qu'il ne devrait pas avoir. Sauf besoin précis et bien compris, ne posez **jamais** SGID sur un exécutable que vous écrivez vous-même. Pour faire collaborer des utilisateurs, on reste sur SGID **côté dossier**.
+
+## Limites de SGID
+
+SGID est efficace, mais il a quelques angles morts qu'il faut connaître :
+
+### Le déplacement (`mv`) ne change pas le groupe
+
+SGID agit seulement à la **création**. Si Alice déplace un fichier depuis son dossier personnel avec `mv mon-fichier.txt /var/www/site/`, le fichier conserve son groupe d'origine (`alice`). C'est `cp` qui crée un nouveau fichier et déclenche l'héritage SGID.
+
+Pour forcer la mise à jour après un `mv`, il faut faire un `chgrp` manuel :
+
+```
+chgrp web-equipe /var/www/site/mon-fichier.txt
+```
+
+### SGID gère le groupe, pas l'utilisateur propriétaire
+
+Le fichier reste la propriété de la personne qui l'a créé. Si Alice crée un fichier en `600` (rw-------), Bob ne pourra rien en faire, SGID ou pas — parce que les droits d'écriture du groupe sont absents. SGID n'est utile que combiné avec des permissions de groupe permissives (`g+rw`) et un umask adapté.
+
+### SGID ne se propage pas aux fichiers existants
+
+Si vous activez SGID sur un dossier qui contient déjà des centaines de fichiers, **leur groupe ne change pas** rétroactivement. Il faut appliquer un `chgrp -R` pour aligner l'existant :
+
+```
+sudo chgrp -R web-equipe /var/www/site
+sudo find /var/www/site -type d -exec chmod g+s {} \;
+```
+
+## L'alternative moderne : les ACL par défaut
+
+SGID est élégant mais limité au **groupe**. Pour des situations plus complexes — par exemple, donner l'écriture à un groupe **et** à un utilisateur spécifique (typiquement `www-data` pour Apache) — les **ACL par défaut** offrent une solution plus expressive :
+
+```
+sudo setfacl -R -d -m g:web-equipe:rwX /var/www/site
+sudo setfacl -R -d -m u:www-data:rwX /var/www/site/uploads
+```
+
+Les ACL par défaut (option `-d`) s'appliquent automatiquement à tout nouveau fichier ou dossier créé. Elles offrent les mêmes garanties que SGID en matière d'héritage, mais permettent de superposer plusieurs règles.
+
+Faut-il choisir l'un ou l'autre ? Les deux approches **se cumulent sans conflit**. La pratique courante est :
+
+- **SGID seul** pour les cas simples (un groupe, des collaborateurs équivalents).
+- **SGID + ACL** quand il faut ajouter des droits ciblés (Apache, un compte de déploiement, un service de sauvegarde).
+
+## Retirer le bit SGID
+
+Si vous voulez désactiver SGID sur un dossier :
+
+```
+sudo chmod g-s /var/www/site
+```
+
+Ou en notation octale, en revenant à des permissions classiques :
+
+```
+sudo chmod 0775 /var/www/site
+```
+
+Le `0` explicite en tête supprime tous les bits spéciaux (SGID, SUID, sticky).
+
+## En résumé
+
+Le bit SGID sur un dossier garantit que **tout nouveau fichier ou sous-dossier hérite du groupe du dossier parent**, transformant un répertoire en véritable espace de travail collaboratif. Il s'active avec `chmod g+s` ou en préfixant les permissions octales par `2`, et se reconnaît dans `ls -l` au `s` dans la colonne du groupe (`rws`).
+
+Pour qu'il soit réellement efficace, trois conditions doivent être réunies :
+
+1. **Les utilisateurs concernés appartiennent au groupe** propriétaire du dossier.
+2. **Les permissions du groupe incluent l'écriture** (`g+w`, donc mode 2770, 2775…).
+3. **Leur umask est permissif** (`0002` en pratique), pour que les fichiers créés soient effectivement modifiables par le groupe.
+
+Sans l'un de ces trois ingrédients, SGID seul ne suffit pas. Avec les trois, vous obtenez un partage de fichiers qui « marche tout seul » — exactement le but recherché.

4d4a4d2b-3380-4675-abb0-e50f29028dc6/meta.json

@@ -0,0 +1,20 @@
+{
+    "uuid": "4d4a4d2b-3380-4675-abb0-e50f29028dc6",
+    "slug": "le-bit-sgid-faire-collaborer-plusieurs-utilisateurs-sur-des-fichiers-partages",
+    "title": "Le bit SGID : faire collaborer plusieurs utilisateurs sur des fichiers partagés",
+    "author": "cedric@abonnel.fr",
+    "published": false,
+    "featured": false,
+    "published_at": "2026-05-17 06:11:15",
+    "created_at": "2026-05-17 06:11:15",
+    "updated_at": "2026-05-17 06:11:15",
+    "revisions": [],
+    "cover": "",
+    "files_meta": [],
+    "external_links": [],
+    "seo_title": "",
+    "seo_description": "",
+    "og_image": "",
+    "category": "",
+    "tags": []
+}

_logs/not_found.jsonl

@@ -1224,3 +1224,4 @@
 {"ts":"2026-05-17 06:00:53","url":"/informatique/serveur/web-linux-apache/nextcloud","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
 {"ts":"2026-05-17 06:03:08","url":"/informatique/linux/commandes/xargs","ref":"https://abonnel.fr/informatique/linux/commandes/xargs","ua":"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; SleepBot/1.0; +http://sleepbot.com/) Chrome/131.0.0.0 Safari/537.36"}
 {"ts":"2026-05-17 06:06:00","url":"/informatique/tpm2","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}
+{"ts":"2026-05-17 06:08:56","url":"/informatique/langage/php/structure-des-dossiers-d-un-projet-php","ref":"","ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36"}