Droits et utilisateurs · Glossaire Linux

Permissions sur les fichiers

Trois actions (lire, écrire, exécuter) × trois cibles (propriétaire, groupe, autres) = neuf bits codés en octal ou symbolique.

`chmod`

Modifier les permissions d'un fichier ou répertoire

Chaque chiffre de la notation octale représente une cible (utilisateur, groupe, autres) et est la somme de :

Notation octale

4	Lecture (`r`)
2	Écriture (`w`)
1	Exécution (`x`)

Exemples courants

755	`rwxr-xr-x` — fichier exécutable lisible par tous.
644	`rw-r--r--` — fichier ordinaire lisible par tous.
700	`rwx------` — répertoire privé ou exécutable réservé au propriétaire. Pour une clé privée SSH, utiliser 600 plutôt que lui ajouter l’exécution.
600	`rw-------` — fichier sensible privé.

Visualisation des 9 bits (mode 755). Chaque groupe — user, group, others — possède trois bits indépendants. Bit actif : couleur d'accent. Bit inactif : grisé avec un -. La somme des bits actifs donne le chiffre octal.

Notation symbolique. Format : [ugoa][+-=][rwx]

Notation symbolique

u / g / o / a	Cible : user, group, others, all.
+ / - / =	Ajouter / retirer / fixer.
r / w / x	Le droit lui-même.

$ chmod 755 script.sh

Rend le script exécutable par tout le monde.

$ chmod u+x deploy.sh

Ajoute uniquement le droit d'exécution pour le propriétaire.

$ chmod -R g+w partagé/

Récursivement, donne le droit d'écriture au groupe sur tout le contenu du dossier.

$ chmod 600 ~/.ssh/id_rsa

Retire les droits du groupe et des autres sur une clé privée. 600 est un choix courant ; 400 peut aussi convenir. SSH vérifie notamment qu’une clé privée n’est pas accessible à d’autres utilisateurs, pas qu’elle possède exactement le mode 600.

Bits spéciaux

4xxx (SUID)	Le binaire s'exécute avec les droits du propriétaire (ex. `/usr/bin/passwd`).
2xxx (SGID)	Le binaire s'exécute avec les droits du groupe. Sur un dossier : nouveaux fichiers héritent du groupe.
1xxx (sticky)	Sur un répertoire : la suppression ou le renommage est réservé au propriétaire du fichier, au propriétaire du répertoire ou à un processus disposant des privilèges nécessaires. Exemple : /tmp.

À éviter : chmod 777 donne tous les droits à tout le monde. Solution de facilité dangereuse, presque toujours inappropriée. Préférez identifier la bonne combinaison propriétaire + groupe.

`chown`

Changer le propriétaire et/ou le groupe d'un fichier

Format : chown utilisateur:groupe fichier. Les deux parties sont optionnelles.

# chown alice rapport.pdf

Donne le fichier à l'utilisateur alice.

# chown alice:devs projet/

Change propriétaire et groupe en une commande.

# chown -R www-data:www-data /var/www/site

Récursif : tout le site appartient à l'utilisateur du serveur web.

# chown :devs partagé.txt

Change uniquement le groupe (le : initial est requis).

Attention : chown -R avec un mauvais utilisateur peut bloquer un service entier. Vérifiez toujours l'utilisateur cible avant.

Élévation des privilèges

Devenir root pour des opérations administratives, ou changer d'identité.

`sudo`

Exécuter une commande avec les droits d'un autre utilisateur (root par défaut)

sudo demande votre propre mot de passe (pas celui de root) et garde une session active de quelques minutes. Les droits sont définis dans /etc/sudoers, à éditer uniquement via visudo qui valide la syntaxe.

Options utiles

-u user	Exécute en tant qu'un autre utilisateur que root.
-i	Ouvre un shell de connexion comme root (équivalent `su -`).
-E	Demande la préservation de l’environnement, dans les limites autorisées par la politique sudo. Certaines variables restent filtrées et cette option peut être refusée.
-l	Liste les commandes que vous avez le droit d'exécuter.

$ sudo apt update

$ sudo -u postgres psql

Lance psql en tant qu'utilisateur postgres — pratique pour administrer la base.

$ sudo !!

Re-lance la commande précédente avec sudo (le grand classique quand on oublie).

`su`

Changer d'utilisateur dans le shell courant

Demande le mot de passe de l'utilisateur cible (et non le vôtre). Sans argument, cible root.

$ su - alice

Ouvre un shell de connexion comme alice et se place dans son répertoire personnel. Bash lit ses fichiers de login (par exemple ~/.bash_profile ou ~/.profile) ; ~/.bashrc n’est chargé que si ces fichiers le demandent.

$ su -c "ls /root" root

Exécute une seule commande en tant que root puis revient.

Gestion des comptes

Créer, modifier, et changer le mot de passe.

`useradd`

Créer un compte utilisateur

Options principales

-m	Crée le répertoire personnel `/home/<nom>`.
-M / --no-create-home	Ne crée pas de répertoire personnel (utile pour un compte de service).
-r / --system	Compte système : UID choisi dans SYS_UID_MIN–SYS_UID_MAX de /etc/login.defs. Pas de home créé par défaut ; l’expiration du mot de passe n’est pas initialisée comme pour un compte ordinaire.
-s SHELL	Shell de connexion. `/bin/bash` pour un humain, `/usr/sbin/nologin` ou `/bin/false` pour un compte non interactif.
-G grp1,grp2	Ajoute aux groupes secondaires.
-c "Nom"	Champ commentaire (visible dans `/etc/passwd`).
-d /chemin	Chemin du home s'il diffère de `/home/<nom>`.

# useradd -m -s /bin/bash -G sudo,devs alice

Exemple Debian/Ubuntu : les groupes sudo et devs doivent exister. Sur Fedora/RHEL, le groupe d’administration est généralement wheel ; adapter -G et vérifier les groupes avec getent avant de créer le compte.

# passwd alice

Définit un mot de passe pour une connexion par mot de passe. Un compte peut utiliser d’autres méthodes d’authentification, par exemple une clé SSH, selon la configuration ; un mot de passe n’est donc pas toujours nécessaire.

Un compte de service dédié limite les droits Unix du programme. Un shell nologin et un mot de passe verrouillé empêchent les connexions ordinaires, mais n’obligent pas à passer par systemd : root peut aussi lancer directement une commande sous cette identité.

# useradd -r -U -s /usr/sbin/nologin -d /var/lib/myapp -M -c "MyApp service" myapp

Crée un compte système avec son groupe privé (-U), pour correspondre à User=myapp et Group=myapp dans l’unité. -r utilise la plage système configurée, -s choisit nologin et -M ne crée pas le home. Le compte est initialement verrouillé pour l’authentification par mot de passe ; le répertoire de données est créé ici par StateDirectory=myapp dans systemd.

$ # /etc/systemd/system/myapp.service
[Unit]
Description=MyApp daemon
After=network.target

[Service]
Type=simple
User=myapp
Group=myapp
ExecStart=/usr/local/bin/myapp
Restart=on-failure
StateDirectory=myapp
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes

[Install]
WantedBy=multi-user.target

L'unité systemd qui consomme le compte. Les directives User= / Group= font tourner le binaire sous l'identité du compte de service. Les options de durcissement (NoNewPrivileges, ProtectSystem=strict, ProtectHome=yes) ajoutent une couche de sandboxing au niveau du noyau, indépendante des permissions Unix.

nologin vs false : /usr/sbin/nologin refuse la connexion avec un message lisible (« This account is currently not available. »), /bin/false sort en silence avec un code 1. Les deux rendent toute connexion interactive impossible ; nologin est plus utile si quelqu'un tente un su - myapp par erreur.

Astuce : sur Debian/Ubuntu, la commande adduser (en français) est plus haut niveau et pose les questions interactivement. Elle reste cependant moins ciblée que useradd -r pour un compte de service — pour les démons, on garde useradd.

Voir aussi : usermod passwd systemctl

`usermod`

Modifier un compte existant

# usermod -aG docker alice

Ajoute alice au groupe docker sans retirer les autres groupes grâce à -aG. Pour un Docker avec démon rootful, l’accès à son socket donne généralement des capacités équivalentes à root : réserver ce groupe aux comptes administrateurs de confiance. Une nouvelle session est normalement nécessaire pour obtenir le groupe.

# usermod -L alice

Verrouille le mot de passe. Une connexion par clé SSH peut rester possible selon la configuration. -U déverrouille le mot de passe. Pour expirer le compte, utiliser séparément usermod --expiredate 1 alice ; cela ne termine pas les sessions ni les processus déjà ouverts.

# usermod -s /bin/zsh alice

Change le shell par défaut.

Piège classique : usermod -G groupe utilisateur sans le -a retire l'utilisateur de tous ses autres groupes. Toujours combiner -aG.

`passwd`

Changer un mot de passe

$ passwd

Change votre propre mot de passe (demande l'ancien).

# passwd alice

En tant que root, change celui d'alice sans connaître l'ancien.

# passwd -l alice

Verrouille le mot de passe. -u pour déverrouiller.

`chage`

Expiration et durée de vie des mots de passe

chage (change age) lit et modifie les champs de durée de vie d'un compte dans /etc/shadow : dernier changement, durée minimale entre deux changements, durée maximale avant obligation de changer, période d'avertissement, période d'inactivité avant verrouillage, date d'expiration. Outil clé pour appliquer une politique de mots de passe en entreprise.

Options principales

-l USER	List : affiche l'état actuel du compte (le seul flag utilisable sans root sur son propre compte).
-M JOURS	Durée maximale d'un mot de passe avant obligation de changement.
-m JOURS	Durée minimale entre deux changements (évite qu'un user contourne l'historique en changeant 5 fois d'affilée).
-W JOURS	Nombre de jours d'avertissement avant l'expiration.
-I JOURS	Inactivité après expiration avant verrouillage du compte.
-E AAAA-MM-JJ	Date d'expiration absolue du compte (différent du mot de passe : verrouille le compte entier).
-d 0	Force le changement de mot de passe à la prochaine connexion.

$ chage -l alice

Last password change                                    : May 14, 2026
Password expires                                        : Aug 12, 2026
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 7

Vue d'audit. Ici le compte exige un changement tous les 90 jours, avec 7 jours d'avertissement. chage -l est utilisable par l'utilisateur lui-même sur son propre compte — pratique pour vérifier quand on va se faire embêter.

# chage -M 90 -W 7 -I 30 alice

Politique typique : mot de passe valable 90 jours, alerte 7 jours avant, compte désactivé 30 jours après expiration si pas de changement. Combiné avec passwd -e pour forcer un premier changement à la prochaine connexion.

# chage -d 0 alice

Marque le mot de passe comme « jamais changé » → forcera alice à le redéfinir à sa prochaine connexion. Idiome après un reset administratif (création de compte avec mot de passe initial communiqué).

# chage -E 2026-12-31 stage-ete

Compte temporaire qui sera verrouillé au 31 décembre 2026 sans intervention. Combine bien avec useradd -e au moment de la création.

Politique globale : les défauts pour les futurs comptes sont dans /etc/login.defs (PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE). chage ne modifie que les comptes existants. Pour propager une politique en masse, un script qui boucle sur getent passwd et lance chage est la pratique courante.

Voir aussi : passwd useradd usermod

Groupes et identité

Gestion des groupes et inspection de l'identité courante.

`groupadd`

Créer un groupe

# groupadd developpeurs

# groupdel developpeurs

Suppression d'un groupe.

Pattern : répertoire partagé entre plusieurs utilisateurs. Quand plusieurs utilisateurs doivent collaborer sur les mêmes fichiers (équipe dev sur un répertoire commun, par exemple), trois ingrédients : un groupe dédié, le bit setgid sur le dossier (les nouveaux fichiers héritent automatiquement du groupe), et une umask qui rend les fichiers éditables par les membres du groupe.

# groupadd projet
usermod -aG projet alice
usermod -aG projet bob
mkdir -p /srv/projet
chgrp projet /srv/projet
chmod 2775 /srv/projet

Crée le groupe et le répertoire partagé avec setgid : les nouveaux fichiers héritent du groupe projet. Les membres ajoutés doivent ouvrir une nouvelle session (ou utiliser newgrp projet) pour que leurs processus obtiennent ce groupe. Le mode 2775 laisse aussi lecture et traversée aux autres ; choisir 2770 pour un répertoire réservé aux membres.

$ # Dans le ~/.bashrc des membres du groupe :
umask 0007

Avec umask 0007, un fichier créé avec le mode de base 0666 reçoit généralement 0660 (rw-rw----) et un répertoire créé avec 0777 reçoit 0770 (rwxrwx---). La umask n’ajoute pas de droit d’exécution ; une application peut demander des droits plus restrictifs et une ACL par défaut peut modifier le calcul.

Voir aussi : usermod chmod umask

`whoami`

Afficher le nom de l'utilisateur courant

$ whoami

dev

Particulièrement utile dans les scripts pour vérifier qu'on tourne bien sous root : [ "$(whoami)" = "root" ] || exit 1.

`id`

Identifiants et groupes de l'utilisateur

$ id

uid=1000(dev) gid=1000(dev) groupes=1000(dev),27(sudo),998(docker)

$ id -u    # UID seul
id -gn   # Nom du groupe primaire
id -nG   # Tous les groupes par leurs noms

`umask`

Permissions par défaut des nouveaux fichiers

umask définit les bits qui seront retirés des permissions par défaut. Les valeurs de base sont 666 pour les fichiers et 777 pour les répertoires.

$ umask
touch test.txt
ls -l test.txt

-rw-r--r-- 1 dev dev 0 mai 12 14:30 test.txt

Avec umask 022 et sans ACL par défaut, un fichier demandé en 0666 reçoit 0644 et un répertoire demandé en 0777 reçoit 0755. Le calcul retire des bits (mode demandé & ~umask) : ce n’est pas une soustraction arithmétique générale.

$ umask 077

Configuration paranoïaque : tous les nouveaux fichiers sont privés (600), dossiers (700).

`getent`

Interroger les bases du système (passwd, group, hosts…)

getent requête les bases de données système via le sous-système NSS (Name Service Switch, configuré dans /etc/nsswitch.conf). Avantage sur un grep /etc/passwd : il voit aussi les comptes/groupes/hôtes provenant de LDAP, NIS, SSSD ou autres backends, pas seulement les fichiers locaux. À privilégier dans les scripts sur des environnements d'entreprise.

Bases interrogeables

`passwd`	Comptes utilisateurs (locaux + LDAP/SSSD).
`group`	Groupes et leurs membres.
`hosts`	Résolution de noms via NSS (combine `/etc/hosts` + DNS).
`services`	Mappage port ↔ nom (`/etc/services`).
`shadow`	Comptes avec hachages (root uniquement).
`networks`	Réseaux nommés.

$ getent passwd alice

alice:x:1001:1001:Alice:/home/alice:/bin/bash

Infos d'un compte au format /etc/passwd classique. Plus fiable que grep ^alice: /etc/passwd dès qu'il peut y avoir des comptes externalisés.

$ getent passwd 1001

Lookup par UID. Pratique quand un fichier appartient à un UID numérique inconnu : getent passwd $(stat -c %u fichier).

$ getent group docker

docker:x:998:alice,bob,charlie

Affiche l’entrée NSS du groupe et sa liste explicite de membres. Cette liste n’inclut pas forcément les utilisateurs dont c’est le groupe primaire ; utiliser id utilisateur pour vérifier l’ensemble des groupes d’un compte.

$ getent hosts api.exemple.fr

93.184.216.34   api.exemple.fr

Résolution DNS qui passe par /etc/hosts et le résolveur système — donc tient compte de l'ordre NSS, contrairement à dig qui parle directement à un serveur DNS. Bon test « est-ce que mon application verra le même résultat ? ».

$ getent services 443

https                 443/tcp

Quel service correspond au port 443 ? Inversement, getent services https donne le numéro.

Voir aussi : id whoami dig

Chiffrement et signatures

Chiffrer un fichier pour qu'il ne soit lisible que par son destinataire, signer pour qu'on puisse vérifier qu'il vient bien de soi. GPG (GNU Privacy Guard) est la boîte à outils historique sous Linux pour ces opérations — utilisée pour les mails (Thunderbird/Enigmail), la signature de paquets (Debian/Ubuntu/RPM), les commits Git signés, et les fichiers sensibles à transmettre.

`gpg`

Chiffrement asymétrique, signatures et gestion de keyring

gpg implémente OpenPGP : on génère une paire de clés (publique + privée), on partage la publique, et n'importe qui peut chiffrer un message à destination de notre clé privée — ou vérifier une signature qu'on a apposée. La clé privée est protégée par une passphrase. Le keyring local stocke les clés (les siennes et celles importées) dans ~/.gnupg/.

Gestion des clés

`--gen-key` / `--full-generate-key`	Génère une nouvelle paire de clés (interactif). `--full` pour choisir algo et durée.
`--list-keys`	Liste les clés publiques du keyring local.
`--list-secret-keys`	Liste les clés secrètes connues du trousseau, y compris des références à une carte ou à un agent ; cela ne prouve pas que leur passphrase est connue ni que la clé est disponible.
`--export -a USER > pub.asc`	Exporte sa clé publique en ASCII armored (à partager par mail/web).
`--import FICHIER`	Importe une clé reçue dans son keyring.
`--delete-keys USER`	Supprime une clé publique (utiliser `--delete-secret-keys` pour une privée).

Chiffrement et signature

`-c FICHIER`	Chiffrement symétrique (passphrase seule, pas de clé). Pratique pour soi-même.
`-e -r DEST FICHIER`	Encrypt à destination du contact `DEST` (cherché dans le keyring).
`-d FICHIER.gpg`	Decrypt : déchiffre vers stdout (ou `-o` pour un fichier).
`--sign FICHIER`	Signe (signature détachée binaire `.sig` avec `--detach-sign`).
`--verify FICHIER.sig FICHIER`	Vérifie la signature.
`-a`	ASCII armored : sortie en texte (extension `.asc`) au lieu de binaire.

$ gpg --full-generate-key

Première étape, une fois par identité. Choisir RSA and RSA, taille 4096, expiration 2 ans (renouvelable). La passphrase doit être solide et mémorisable — elle débloque la clé privée à chaque usage. Les clés résultantes sont stockées dans ~/.gnupg/.

$ gpg --list-keys
gpg --export -a alice@example.test > alice-pub.asc

Vérifier ses clés et exporter sa publique pour la partager (par mail, sur un keyserver, sur sa page web). Le fichier .asc contient un bloc texte lisible commençant par -----BEGIN PGP PUBLIC KEY BLOCK-----.

$ gpg -c secret.txt

Chiffrement symétrique rapide : passphrase tapée à l'invite, produit secret.txt.gpg. Idéal pour stocker un mot de passe ou un fichier sensible localement, sans avoir à gérer des clés. La passphrase est la seule chose qui permettra de déchiffrer.

$ gpg -e -r bob@example.test rapport.pdf

Chiffrement asymétrique : produit rapport.pdf.gpg que seul Bob (avec sa clé privée) pourra déchiffrer. Sa clé publique doit avoir été importée au préalable. Plusieurs -r permettent de chiffrer pour plusieurs destinataires d'un coup.

$ gpg --output rapport-dechiffre.pdf --decrypt rapport.pdf.gpg

Déchiffre vers un autre nom pour éviter de tronquer un fichier existant par une redirection shell avant de savoir si le déchiffrement réussit. GnuPG affiche une erreur si la clé nécessaire manque et peut demander une passphrase selon l’état de l’agent.

$ gpg --detach-sign -a release.tar.gz       # produit release.tar.gz.asc
gpg --verify release.tar.gz.asc release.tar.gz

Signature détachée : on ne modifie pas le fichier original, on crée juste un .asc à côté. Pattern classique pour distribuer un logiciel — l'utilisateur peut télécharger l'archive et la signature, vérifier que la signature correspond à la clé publique du mainteneur, et donc que le fichier n'a pas été altéré.

Trust on first use : Une signature correcte prouve la correspondance avec une clé, pas l’identité de son propriétaire. Comparer l’empreinte complète avec une source authentifiée. Dans le modèle Web of Trust, trust règle la confiance accordée au propriétaire pour certifier d’autres clés ; cela ne valide pas simplement sa propre identité. Après vérification, une certification locale gpg --lsign-key EMPREINTE est une opération distincte.

Sauvegarder ses clés : perdre la clé privée = perdre l'accès à tout ce qu'on a chiffré. Faire un export sécurisé hors-ligne : gpg --export-secret-keys -a alice@example.test > backup.asc puis stocker ce fichier sur un support hors-ligne (clé USB chiffrée, papier imprimé), pas dans le cloud. La passphrase reste indispensable pour utiliser la clé restaurée.

Voir aussi : ssh chmod tar

Contrôle d'accès (SELinux)

Au-dessus des permissions classiques (rwx, propriétaire/groupe), SELinux ajoute un contrôle d'accès obligatoire (MAC) : même root est contraint par une politique. Présent et actif par défaut sur Red Hat / Fedora / CentOS / Rocky / Alma. Quand « ça marche en désactivant SELinux », c'est presque toujours un contexte de fichier ou un booléen à corriger — pas une raison de le couper.

`getenforce · setenforce · semanage · restorecon`

Inspecter et corriger les contextes SELinux

Chaque fichier et chaque processus porte un contexte (user:role:type:level) ; la politique autorise ou refuse selon ces types. La grande majorité des soucis se résument à deux causes : un contexte de fichier incorrect (fichier déplacé avec mv qui conserve son ancien contexte) ou un booléen à activer. Les outils ci-dessous diagnostiquent et corrigent.

Modes et état

`getenforce`	Mode courant : `Enforcing` (applique), `Permissive` (journalise sans bloquer), `Disabled`.
`sestatus`	État détaillé (mode courant, mode au boot, politique chargée).
`setenforce 0` / `1`	Bascule Permissive / Enforcing temporairement (perdu au reboot). Permanent : `/etc/selinux/config`.
`ls -Z` / `ps -Z`	Affiche le contexte SELinux des fichiers / processus.

# getenforce
ls -Z /var/www/html/index.html

Enforcing
unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Le type httpd_sys_content_t est ce qui autorise Apache à lire le fichier. Si une page renvoie un 403 alors que les permissions rwx sont correctes, c'est typiquement ce contexte qui cloche.

# restorecon -Rv /var/www/html
semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

restorecon réapplique le contexte par défaut attendu pour le chemin — la correction la plus fréquente, après un mv. Pour un chemin non standard (servir le web depuis /srv), on enregistre d'abord la règle avec semanage fcontext puis on l'applique. chcon ferait un changement ponctuel, mais non persistant à un restorecon ultérieur.

# getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Les booléens activent des comportements sans toucher aux contextes — ici, autoriser Apache à ouvrir des connexions sortantes (proxy, base distante). -P rend le réglage permanent.

Diagnostiquer un refus : les blocages SELinux sont journalisés dans /var/log/audit/audit.log. ausearch -m avc -ts recent liste les refus récents, et audit2why les explique en clair (souvent avec la commande exacte pour corriger). Passer brièvement en Permissive confirme que SELinux est bien la cause avant de chercher la règle.

Voir aussi : chmod chown journalctl