Fondamentalement, chaque fichier d'un système de fichiers Linux appartient à un utilisateur et à un groupe. Chacun de ces groupes propriétaires et tous les autres sont autorisés à écrire, lire ou exécuter ces fichiers.

Dans ce cas, un groupe peut être défini comme un ensemble d'utilisateurs connectés ayant certains droits collectifs. Par exemple, appelez un groupe travaillant sur un certain projet project3. Chaque utilisateur d'un système Linux est membre d'au moins un groupe propriétaire, en principe celui des users. Un système peut comprendre autant de groupes que nécessaire, mais seul un superutilisateur peut ajouter des groupes. La commande groups permet à chaque utilisateur de savoir à quel groupe il appartient.

Dans certaines situations, les autorisations d'accès peuvent être trop restrictives. C'est pourquoi Linux possède des paramètres supplémentaires permettant de modifier provisoirement l'identité actuelle de l'utilisateur et du groupe pour une action spécifique. Par exemple, le programme passwd requiert normalement des autorisations de niveau racine pour accéder à /etc/passwd. Ce fichier contient des informations importantes (par exemple, les répertoires privés des utilisateurs, ainsi que les ID des utilisateurs et des groupes). Un utilisateur ordinaire n'est donc pas en mesure de changer le fichier passwd, car cela serait trop dangereux d'accorder un accès direct à ce fichier à l'ensemble des utilisateurs. Le mécanisme setuid offre une solution à ce problème. setuid (pour « set user ID ») est un attribut de fichier spécial qui indique au système d'exécuter certains programmes sous un ID utilisateur spécifique. Imaginons la commande passwd :

-rwsr-xr-x  1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd

Le s indique que le bit setuid est défini pour l'autorisation de l'utilisateur. Grâce au bit setuid, tous les utilisateurs qui lancent la commande passwd l'exécutent en tant que root.

Le bit setuid s'applique aux utilisateurs. Toutefois, il existe également une propriété équivalente pour les groupes : le bit setgid. Un programme pour lequel cet attribut a été défini est exécuté sous l'ID groupe sous lequel il a été enregistré, quel que soit l'utilisateur qui le lance. Par conséquent, dans un répertoire comprenant le bit setgid, tous les fichiers et sous-répertoires nouveaux sont assignés au groupe auquel appartient le répertoire. Prenez pour exemple le répertoire suivant :

drwxrws--- 2 tux archive 48 Nov 19 17:12
   backup

Le s indique que le bit setuid est défini pour l'autorisation du groupe. Le propriétaire du répertoire et les membres du groupe archive peuvent accéder à ce répertoire. Les utilisateurs qui ne sont pas membres de ce groupe sont « assignés » à leur groupe respectif. L'ID de groupe effectif de tous les fichiers écrits sera archive. Par exemple, un programme de sauvegarde qui est exécuté avec l'ID de groupe archive peut accéder à ce répertoire, même s'il n'est pas doté des privilèges de niveau racine.

Il existe également le bit autocollant. Son utilisation est différente selon qu'il appartient à un programme exécutable ou à un répertoire. S'il appartient à un programme, un fichier marqué de cette façon est chargé dans la mémoire RAM pour éviter d'avoir à l'extraire du disque dur à chacune de ces utilisations. Cet attribut est rarement utilisé car les disques durs modernes sont suffisamment rapides. Si ce bit est assigné à un répertoire, il empêche les utilisateurs de supprimer leurs fichiers respectifs. Des exemples typiques sont les répertoires /tmp et /var/tmp :

drwxrwxrwt   2 root  root   1160 2002-11-19 17:15 /tmp
  

Le concept classique d'autorisation pour les objets du système de fichiers Linux, tels que les fichiers ou les répertoires, peut être développé au moyen des ACL (listes de contrôle d'accès). Elles permettent d'assigner des autorisations à des utilisateurs ou groupes individuels autres que le propriétaire ou le groupe propriétaire d'origine d'un objet du système de fichiers.

Les fichiers ou répertoires qui comportent des autorisations d'accès étendues peuvent être détectés à l'aide d'une simple commande ls -l :

-rw-r--r--+ 1 tux project3 14197 Jun 21  15:03 Roadmap

Roadmap est détenu par tux qui appartient au groupe project3. tux possède à la fois les droits d'écriture et de lecture sur ce fichier. Son groupe, comme tous les autres utilisateurs, possèdent des droits de lecture. La seule différence qui distingue ce fichier d'un fichier sans ACL est le + supplémentaire qui apparaît dans la première colonne comportant les bits d'autorisation.

Pour obtenir des détails sur l'ACL, exécutez la commande getfacl Roadmap :

# file: Roadmap 
# owner: tux 
# group: project3 
user::rw- 
user:jane:rw-       effective: r-- 
group::r-- 
group:djungle:rw-   effective: r-- 
mask::r-- 
other::---

Les trois premières lignes de la sortie ne comportent aucune information qui n'est pas disponible avec la commande ls -l. Ces lignes indiquent uniquement le nom du fichier, le propriétaire et le groupe propriétaire. Les lignes 4 à 9 comportent les entrées ACL. Les autorisations d'accès conventionnelles représentent un sous-ensemble des autorisations possibles en utilisant les ACL. Cet exemple d'ACL accorde les droits de lecture et d'écriture au propriétaire du fichier, ainsi qu'à l'utilisateur jane (lignes 4 et 5). Le concept conventionnel a été développé pour offrir l'accès à un utilisateur supplémentaire. Le même principe s'applique à la gestion d'un accès de groupe. Le groupe propriétaire possède des droits de lecture (ligne 6) et le groupe djungle des droits de lecture et d'écriture. L'entrée de la commande mask à la ligne 8 réduit les droits de lecture effectifs de l'utilisateur jane et du groupe djungle. Les autres utilisateurs et groupes ne bénéficient d'aucun accès au fichier (ligne 9).

Seules des informations très basiques sont fournies ici. Pour plus d'informations sur les ACL, reportez-vous au Chapitre 24, Listes de contrôle d'accès sous Linux.