[Article] Users, groups, sudo and permissions

1. Comptes et groupes #

Qui peut se connecter et avec quelle identité.

Les fichiers de comptes #

Fichier	Contenu
`/etc/passwd`	nom:x:UID:GID:commentaire:répertoire:shell (lisible par tous)
`/etc/shadow`	empreintes des mots de passe et expiration (root uniquement)
`/etc/group`	groupes et membres secondaires
`/etc/sudoers`, `/etc/sudoers.d/`	règles sudo

Chaque compte a un UID : 0 pour root, moins de 1000 pour les comptes système (services), 1000 et plus pour les humains. Les services tournent sous des comptes système sans shell (/usr/sbin/nologin) pour limiter les dégâts en cas de compromission.

Gérer les comptes #

sudo useradd -m -s /bin/bash -c "Alice Martin" alice   # créer avec répertoire personnel
sudo passwd alice                     # définir le mot de passe
sudo usermod -aG devs,docker alice    # ajouter à des groupes (-a indispensable !)
sudo chage -M 90 -W 7 alice           # expiration du mot de passe à 90 jours
sudo chage -l alice                   # politique d'expiration
sudo usermod -L alice                 # verrouiller ; -U pour déverrouiller
sudo userdel -r bob                   # supprimer avec son répertoire
sudo useradd -r -s /usr/sbin/nologin -d /srv/app app   # compte de service
id alice ; groups alice ; getent passwd alice
who ; w ; last -n 10 ; lastlog         # qui est connecté, historique

Groupes #

sudo groupadd devs
sudo gpasswd -d alice docker   # retirer d'un groupe
newgrp devs                    # activer un nouveau groupe sans se reconnecter

Erreur Courante : usermod -G devs alice sans -a remplace tous les groupes secondaires d'alice : elle perd par exemple le groupe sudo.

2. sudo #

Déléguer les droits root sans partager le mot de passe.

Principe #

Fonctionnement de sudo — Chaque commande est attribuée à une personne : la traçabilité est préservée.

sudo exécute une commande sous une autre identité (root par défaut) après authentification de l'utilisateur, et journalise chaque commande. On ne se connecte jamais directement en root : chacun utilise son compte nominatif, ce qui garde la traçabilité.

sudo -l                          # ce que j'ai le droit de faire
sudo -i                          # shell root (journalisé)
sudo -u postgres psql            # exécuter en tant qu'un autre utilisateur
sudo visudo -f /etc/sudoers.d/devs   # éditer avec vérification de syntaxe
journalctl _COMM=sudo --since today  # audit des commandes sudo

Règles #

# /etc/sudoers.d/devs
# utilisateur/groupe  hôtes=(identité)  commandes
%sudo   ALL=(ALL:ALL) ALL
%devs   ALL=(root) /usr/bin/systemctl restart app, /usr/bin/journalctl -u app*
deploy  ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh

Bonne Pratique : Accordez des commandes précises plutôt que ALL, et n'autorisez jamais via sudo un éditeur, less ou un script modifiable par l'utilisateur : ils permettent d'obtenir un shell root.

Erreur Courante : Éditez toujours avec visudo : une erreur de syntaxe dans sudoers peut bloquer tout accès root.

3. Permissions #

Lire, écrire, exécuter.

Lire les droits #

Décomposition des permissions — r = 4, w = 2, x = 1 : on additionne pour chaque catégorie.

Droit	Sur un fichier	Sur un répertoire
r (4)	lire le contenu	lister les noms
w (2)	modifier	créer, renommer, supprimer des fichiers
x (1)	exécuter	traverser (cd, accéder aux fichiers)

Ordre d'évaluation des permissions — Un propriétaire en r-- ne peut pas écrire, même si le groupe a rw-.

Modifier #

chmod 640 secret.conf            # rw- r-- ---
chmod u+x deploy.sh              # ajouter l'exécution au propriétaire
chmod -R g+rwX /srv/projet       # X : exécution seulement sur les répertoires
sudo chown alice:devs fichier    # changer propriétaire et groupe
sudo chown -R www-data: /srv/www # groupe principal de l'utilisateur
find /srv -type d -exec chmod 2775 {} +   # appliquer aux seuls répertoires

umask #

Le umask retire des droits aux fichiers créés. Avec umask 022, un fichier est créé en 644 et un répertoire en 755 ; avec 027, en 640 et 750 (rien pour les autres).

umask ; umask 027   # valeur courante, puis plus restrictive pour la session

4. Droits spéciaux, ACL et attributs #

Quand rwx ne suffit pas.

SUID, SGID et sticky bit #

Bit	Notation	Effet
SUID (4000)	`rws------`	le programme s'exécute avec les droits de son propriétaire (ex. `passwd`)
SGID (2000) sur un répertoire	`rwxrws---`	les fichiers créés héritent du groupe du répertoire : idéal pour un dossier d'équipe
Sticky (1000)	`rwxrwxrwt`	seul le propriétaire peut supprimer ses fichiers (ex. `/tmp`)

sudo chmod 2770 /srv/equipe            # dossier partagé avec héritage du groupe
find / -xdev -perm -4000 -type f 2>/dev/null   # inventaire des binaires SUID (audit)

Héritage du groupe avec SGID — Avec un umask 002, tous les membres de devs peuvent modifier les fichiers de l'équipe.

ACL #

Les ACL donnent des droits à des utilisateurs ou groupes supplémentaires, sans changer le propriétaire. Un + à la fin des droits dans ls -l signale une ACL.

setfacl -m u:bob:rx /srv/rapports          # droit pour bob
setfacl -d -m g:audit:r /srv/rapports      # ACL par défaut, héritée par les nouveaux fichiers
getfacl /srv/rapports
setfacl -b /srv/rapports                   # supprimer toutes les ACL

Attributs #

sudo chattr +i /etc/resolv.conf   # immuable, même pour root
sudo chattr +a /var/log/audit.log  # ajout uniquement
lsattr /etc/resolv.conf

Users, groups, sudo and permissions