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

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é.