Dans le dernier article (Série RHCSA Partie 6), nous avons commencé à expliquer comment configurer et configurer le stockage système local en utilisant parted et ssm.
Nous avons également discuté de la création et du montage de volumes chiffrés avec un mot de passe lors du démarrage du système. De plus, nous vous avons avertis d’éviter d’effectuer des opérations critiques de gestion du stockage sur des systèmes de fichiers montés. Avec cela à l’esprit, nous passerons maintenant en revue les formats de système de fichiers les plus utilisés dans Red Hat Enterprise Linux 7 et ensuite aborder les sujets du montage, de l’utilisation et du démontage à la fois manuellement et automatiquement des systèmes de fichiers réseau (CIFS et NFS), ainsi que la mise en œuvre de listes de contrôle d’accès pour votre système.
Prérequis
Avant de continuer, assurez-vous d’avoir un serveur Samba et un serveur NFS disponibles (notez que NFSv2 n’est plus pris en charge dans RHEL 7).
Dans ce guide, nous utiliserons une machine avec IP 192.168.0.10 avec les deux services en cours d’exécution en tant que serveur, et une machine RHEL 7 en tant que client avec l’adresse IP 192.168.0.18. Plus tard dans l’article, nous vous dirons quels packages vous devez installer sur le client.
Formats de Système de Fichiers dans RHEL 7
À partir de RHEL 7, XFS a été introduit comme système de fichiers par défaut pour toutes les architectures en raison de ses performances élevées et de sa scalabilité. 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 permet user_xattr (attributs d’utilisateur étendus) et acl (listes de contrôle d’accès POSIX) en tant qu’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 soit en ligne de commande, soit dans /etc/fstab lors du montage d’un système de fichiers XFS (si vous souhaitez désactiver de telles options dans ce dernier cas, vous devez utiliser explicitement no_acl et no_user_xattr).
Gardez à l’esprit que les attributs d’utilisateur étendus peuvent être assignés aux fichiers et répertoires pour stocker des informations supplémentaires arbitraires telles que le type MIME, l’ensemble de caractères ou le codage d’un fichier, tandis que les autorisations d’accès pour les attributs d’utilisateur sont définies par les bits de permission de fichier réguliers.
Listes de contrôle d’accès
Comme tout administrateur système, qu’il soit débutant ou expert, est bien familiarisé avec les autorisations d’accès régulières sur les 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). Cependant, n’hésitez pas à vous référer à la Partie 3 de la série RHCSA si vous avez besoin de rafraîchir un peu votre mémoire.
Cependant, étant donné que l’ensemble standard ugo/rwx ne permet pas de configurer des autorisations différentes pour différents utilisateurs, ACLs 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 sur-ensemble des autorisations spécifiées par les bits de permission du fichier. Voyons comment tout cela est appliqué dans le monde réel.
1. Il existe deux types de ACLs: les ACL d’accès, qui peuvent être appliquées à un fichier spécifique ou à un répertoire, et les ACL par défaut, qui ne peuvent être appliquées qu’à un répertoire. Si les fichiers qu’il contient 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 un utilisateur qui n’appartient pas au groupe propriétaire d’un fichier.
3. Les ACLs sont définis (et supprimés) en utilisant setfacl, avec les options -m ou -x, respectivement.
Par exemple, créons un groupe nommé tecmint et ajoutons les utilisateurs johndoe et davenull à celui-ci:
# 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 définirons le propriétaire du groupe sur tecmint et changerons ses autorisations par défaut ugo/rwx en 770 (autorisant la lecture, l’écriture et l’exécution pour 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
Ensuite, changez d’utilisateur pour 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. Maintenant, laissons l’utilisateur gacanepa écrire dans le fichier – et l’opération d’écriture échouera, ce qui était prévisible.
Mais que faire si nous avons réellement besoin que l’utilisateur gacanepa (qui n’est pas membre du groupe tecmint) ait des autorisations d’écriture sur /mnt/playground/testfile.txt? La première chose qui vous vient à l’esprit est d’ajouter ce compte utilisateur au groupe tecmint. Mais cela lui donnera des autorisations d’écriture sur TOUS les fichiers pour lesquels le bit d’écriture est défini pour le groupe, et nous ne voulons pas 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 l’accès en lecture et en écriture à /mnt/playground/testfile.txt.
Exécutez en tant que root,
# setfacl -R -m u:gacanepa:rwx /mnt/playground
et vous aurez ajouté avec succès un ACL qui permet à gacanepa d’écrire dans le fichier de test. Ensuite, passez à l’utilisateur gacanepa et essayez d’écrire à nouveau dans le fichier:
$ echo "My name is Gabriel Canepa" >> /mnt/playground/testfile.txt
Pour afficher les ACLs d’un fichier ou d’un répertoire spécifique, utilisez getfacl:
# getfacl /mnt/playground/testfile.txt
Pour définir un ACL par défaut pour un répertoire (dont le contenu héritera sauf indication 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 qui ne sont pas dans le groupe propriétaire d’avoir accès en lecture aux futurs contenus du répertoire /mnt/playground. Notez la différence dans la sortie de getfacl /mnt/playground avant et après le changement:
Le chapitre 20 du Guide de l’administration du stockage officiel de RHEL 7 fournit plus d’exemples d’ACL, et je vous recommande vivement d’y jeter un coup d’œil et de l’avoir à portée de main comme référence.
Source:
https://www.tecmint.com/rhcsa-exam-configure-acls-and-mount-nfs-samba-shares/