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 cdrecord nécessite en fait des permissions root pour accéder au graveur pour graver des CD (ou DVD). En effet, par défaut, un utilisateur normal ne peut pas créer des CD car il serait trop dangereux d'accorder à tous les utilisateurs l'accès direct à tous les périphériques.

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 le programme cdrecord :

-rwxr-x---  1 root root  281356 2002-10-08 21:30 /usr/bin/cdrecord

Définissez le bit setuid à l'aide de la commande chmod u+s /usr/bin/cdrecord. Puis, avec la commande chgrp users /usr/bin/cdrecord, le programme cdrecord est attribué au groupe users.

Les droits d'accès suivants sont accordés :

-rws--x---  1 root users  281356 2002-10-08 21:30 /usr/bin/cdrecord

Grâce au bit setuid, tous les utilisateurs qui appartiennent au groupe users peuvent utiliser le programme. En pratique, ceci signifie que le programme est exécuté en tant qu'utilisateur root.

	Avertissement
Veuillez noter qu'attribuer le bit setuid à un programme rend votre ordinateur plus vulnérable aux attaques. Ceci ne doit être fait que dans des cas exceptionnels si vous connaissez parfaitement le programme et pouvez en évaluer les risques potentiels.

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 de répertoire suivant :

drwxrwxr--   2 root  archive    48 Nov 19 17:12 backup

Attribuons maintenant le bit setgid avec la commande chmod g+s /test

Les droits d'accès seront alors comme suit :

drwxrwsr--   2 root  archive    48 Nov 19 17:12 backup

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. Pour les fichiers, ce bit n'est aujourd'hui pratiquement plus utilisé et n'a plus qu'une signification historique.

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, ACL Access Control Lists représente 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   517 2003-01-08 18:12 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 conséquentes dans le guide de l'administrateur, au chapitre Access Control Lists sous Linux.