Série RHCSA : Utilisation des ACL (listes de contrôle d'accès) et montage de partages Samba/NFS - Partie 7

Depuis RHEL 7, XFS a été introduit comme système de fichiers par défaut pour toutes les architectures en raison de ses hautes performances et de son évolutivité. Il prend actuellement en charge une taille maximale de système de fichiers de 500 To, selon les derniers tests effectués par Red Hat et ses partenaires pour le matériel grand public.

De plus, XFS active user_xattr (attributs utilisateur étendus) et acl (listes de contrôle d'accès POSIX) comme options de montage par défaut, contrairement à ext3 ou ext4 (ext2 est considéré comme obsolète à partir de RHEL 7), ce qui signifie que vous n'avez pas besoin de spécifier ces options explicitement ni sur la ligne de commande ni dans /etc/fstab lors du montage d'un système de fichiers XFS (si vous souhaitez désactivez ces options dans ce dernier cas, vous devez utiliser explicitement no_acl et no_user_xattr).

Gardez à l'esprit que les attributs utilisateur étendus peuvent être attribués à des fichiers et des répertoires pour stocker des informations supplémentaires arbitraires telles que le type MIME, le jeu de caractères ou l'encodage d'un fichier, tandis que les autorisations d'accès aux attributs utilisateur sont définies par les bits d'autorisation de fichier normaux.

Listes de contrôle d'accès

Comme tout administrateur système, qu'il soit débutant ou expert, connaît bien les autorisations d'accès régulières aux fichiers et répertoires, qui spécifient certains privilèges (lecture, écriture et exécution). ) pour le propriétaire, le groupe et « le monde » (tous les autres). N’hésitez cependant pas à vous référer à la partie 3 de la série RHCSA si vous avez besoin de vous rafraîchir un peu la mémoire.

Cependant, comme l'ensemble standard ugo/rwx ne permet pas de configurer différentes autorisations pour différents utilisateurs, des ACL ont été introduites afin de définir des droits d'accès plus détaillés pour les fichiers et répertoires que ceux spécifiés par les autorisations régulières.

En fait, les autorisations définies par ACL sont un surensemble des autorisations spécifiées par les bits d'autorisation de fichier. Voyons comment tout cela se traduit et appliqué dans le monde réel.

1. Il existe deux types de ACL : les ACL d'accès, qui peuvent être appliquées soit à un fichier spécifique, soit à un répertoire), et ACL par défaut, qui ne peuvent être appliquées qu'à un répertoire. Si les fichiers qu'ils contiennent n'ont pas d'ACL définie, ils héritent de l'ACL par défaut de leur répertoire parent.

2. Pour commencer, les ACL peuvent être configurées par utilisateur, par groupe ou par utilisateur ne faisant pas partie du groupe propriétaire d'un fichier.

3. Les ACL sont définies (et supprimées) à l'aide de setfacl, avec -m ou - x options, respectivement.

Par exemple, créons un groupe nommé tecmint et ajoutons-y les utilisateurs johndoe et davenull :

groupadd tecmint
useradd johndoe
useradd davenull
usermod -a -G tecmint johndoe
usermod -a -G tecmint davenull

Et vérifions que les deux utilisateurs appartiennent au groupe supplémentaire tecmint :

id johndoe
id davenull

Créons maintenant un répertoire appelé Playground dans /mnt, et un fichier nommé testfile.txt à l'intérieur. Nous allons définir le propriétaire du groupe sur tecmint et modifier ses autorisations par défaut ugo/rwx en 770 (autorisations de lecture, d'écriture et d'exécution accordées aux deux le propriétaire et le propriétaire du groupe du fichier) :

mkdir /mnt/playground
touch /mnt/playground/testfile.txt
chmod 770 /mnt/playground/testfile.txt

Changez ensuite d'utilisateur sur johndoe et davenull, dans cet ordre, et écrivez dans le fichier :

echo "My name is John Doe" > /mnt/playground/testfile.txt
echo "My name is Dave Null" >> /mnt/playground/testfile.txt

Jusqu'ici, tout va bien. Laissons maintenant l'utilisateur gacanepa écrire dans le fichier – et l'opération d'écriture échouera, ce qui était prévisible.

Mais que se passe-t-il si nous avons réellement besoin que l'utilisateur gacanepa (qui n'est pas membre du groupe tecmint) ait des autorisations en écriture sur /mnt/playground/testfile.txt ?< La première chose qui peut vous venir à l'esprit est d'ajouter ce compte utilisateur au groupe tecmint. Mais cela lui donnera des autorisations d'écriture sur TOUS les fichiers où le bit d'écriture est défini pour le groupe, et nous ne voulons pas de cela. Nous voulons seulement qu'il puisse écrire dans /mnt/playground/testfile.txt.

touch /mnt/playground/testfile.txt
chown :tecmint /mnt/playground/testfile.txt
chmod 777 /mnt/playground/testfile.txt
su johndoe
echo "My name is John Doe" > /mnt/playground/testfile.txt
su davenull
echo "My name is Dave Null" >> /mnt/playground/testfile.txt
su gacanepa
echo "My name is Gabriel Canepa" >> /mnt/playground/testfile.txt

Donnons à l'utilisateur gacanepa un accès en lecture et en écriture à /mnt/playground/testfile.txt.

Exécuter en tant que root,

setfacl -R -m u:gacanepa:rwx /mnt/playground

et vous aurez ajouté avec succès une ACL qui permet à gacanepa d'écrire dans le fichier de test. Passez ensuite à l'utilisateur gacanepa et essayez à nouveau d'écrire dans le fichier :

echo "My name is Gabriel Canepa" >> /mnt/playground/testfile.txt

Pour afficher les ACL d'un fichier ou d'un répertoire spécifique, utilisez getfacl :

getfacl /mnt/playground/testfile.txt

Pour définir une ACL par défaut sur un répertoire (dont son contenu héritera sauf écrasement contraire), ajoutez d: avant la règle et spécifiez un répertoire au lieu d'un nom de fichier :

setfacl -m d:o:r /mnt/playground

L'ACL ci-dessus permettra aux utilisateurs ne faisant pas partie du groupe propriétaire d'avoir un accès en lecture au contenu futur du répertoire /mnt/playground. Notez la différence dans le résultat de getfacl /mnt/playground avant et après le changement :

Le chapitre 20 du guide officiel d'administration du stockage RHEL 7 fournit davantage d'exemples d'ACL, et je vous recommande fortement d'y jeter un œil et de l'avoir à portée de main comme référence.