Dans le système de fichiers Linux, un fichier appartient toujours à un utilisateur et à un groupe. Le propriétaire du fichier peut assigner à ces deux parties mais aussi à des utilisateurs externes des droits de lecture, d'écriture et d'exécution.

On désigne sous le nom de groupe l'ensemble des utilisateurs d'un système qui possèdent certains droits collectifs. Une équipe travaillant à la réalisation d'un projet et que nous appellerons projet3 constitue un tel groupe. Chaque utilisateur sous Linux fait partie, au minimum, d'une unité de gestion qui est par défaut le groupe users. Il est possible de créer plusieurs autres groupes mais seul root est autorisé à prendre cette mesure. Avec la commande groups, chaque utilisateur peut savoir à quel groupe il appartient.

Dans certaines situations, les droits d'accès peuvent sembler trop restrictifs. À cette fin, il existe sous Linux des paramètres supplémentaires qui permettent la modification temporaire de l'identité de l'utilisateur et du groupe courants pour une action spécifique. Par exemple, le programme passwd nécessite en fait des permissions root pour accéder à /etc/passwd. Ce fichier contient des informations importantes telles que les répertoires personnels des utilisateurs et les ID des utilisateurs et groupes. Ainsi, un utilisateur normal ne peut pas modifier passwd car il serait trop dangereux d'accorder à tous les utilisateurs l'accès direct à ce fichier. Le mécanisme setuid offre une solution à ce problème. Setuid (Set User ID) est un attribut de fichier spécial qui indique au système qu'il doit exécuter les programmes marqués par cet attribut sous un ID utilisateur spécifique. Considérons la commande passwd :

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

Vous pouvez voir le bit s défini pour les droits de l'utilisateur. Avec le bit setuid, tous les utilisateurs qui démarrent la commande passwd l'exécute en tant que root.

L'attribut setuid s'applique à l'utilisateur, mais il existe une propriété équivalente pour les groupes : l'attribut setgid. Un programme fonctionne alors sous l'ID de groupe sous lequel il a été enregistré quelque soit l'utilisateur qui l'adémarré. En conséquence, dans un répertoire avec le bit setgid, tous les nouveaux fichiers et sous-répertoires créés seront attribués au groupe auquel est attribué le répertoire. Considérons l'exemple suivant :

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

Vous pouvez voir le bit s défini pour les droits du groupe. Le propriétaire du répertoire et les membres du groupe archive peuvent accéder au répertoire. Les utilisateurs qui ne sont pas membres de ce groupe sont « mappés » au 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 pourra accéder à ce répertoire sans même jouir des privilèges de root.

Outre les bits setuid et setgid, il existe également le bit sticky. Il faut ici différencier le cas où le bit sticky appartient à un programme exécutable du cas où il appartient à un répertoire. S'il appartient à un programme, un fichier marqué de cette façon est chargé dans le RAM pour éviter d'avoir à le charger depuis le disque dur à chaque fois qu'il est utilisé. Cet attribut est rarement utilisé parce que les disques durs modernes sont suffisamment rapides. Par contre, si cet attribut est assigné à un répertoire, cela empêche les utilisateurs de s'effacer les fichiers réciproquement (dans les répertoires avec le bit sticky, les utilisateurs n'ont le droit d'effacer que les fichiers dont ils sont propriétaires). Les répertoires /tmp et /var/tmp en sont des exemples typiques :

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

Sous Linux, les listes de contrôle d'accès (ACL, en anglais Access Control Lists) représentent une extension du concept de permissions traditionnel pour les fichiers et répertoires. À l'aide des ACL, des permissions peuvent être attribuées à des utilisateurs ou à des groupes autres que l'utilisateur ou le groupe propriétaire d'origine.

Vous pouvez reconnaitre les répertoires ou fichiers dont les droits d'accès sont étendus tout simplement à l'aide de la commande ls -l :

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

Au premier coup d'œil, la sortie de la commande ls n'a pas beaucoup changé. Le fichier Roadmap appartient à l'utilisateur tux qui lui même fait partie du groupe projet3. tux possède aussi bien les droits d'accès en lecture qu'en écriture, le groupe possède les droits d'accès en lecture ainsi que tous les autres utilisateurs. Le seul détail indiquant une différence avec un fichier sans ACL est le + supplémentaire dans la première colonne des bits de permissions.

Vous obtenez des détails relatifs à l'ACL en exécutant la commande getfacl pour votre fichier exemple Roadmap :

# file: Roadmap
# owner: tux
# group: projet3
user::rw-
user:jane:rw-       effective: r--
group::r--
group:jungle:rw-   effective: r--
mask::r--
other::---

Les trois premières lignes n'apportent aucune information nouvelle par rapport à celles obtenues avec la commande ls -l. Il ne s'agit ici que du nom du fichier, du propriétaire et du groupe. De la quatrième à la neuvième ligne sont affichées les données ACL (ACL entries). Les droits d'accès conventionnels représentent un sous-ensemble de permissions que l'on peut définir à l'aide des ACL. Ici, l'exemple d'ACL attribue des droits d'accès en lecture et en écriture au propriétaire du fichier ainsi qu'à l'utilisateur jane (lignes 4 et 5) ; il s'agit donc d'une extension des permissions conventionnelles. La même chose est valable pour les groupes : le groupe propriétaire du fichier possède les droits d'accès en lecture (ligne 6), le groupe jungle se voyant lui attribuer des droits d'accès en lecture et en écriture (ligne 7). L'entrée mask en ligne 8 limite les droits d'accès effectifs pour l'utilisateur jane et le groupe jungle à la lecture. Aucun autre utilisateur ou groupe ne se voit accorder de permissions d'accès au fichier (ligne 9).

Vous trouverez des informations plus détaillées dans le guide de l'administrateur.