Permissions sous Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)

Bonjour à tous. Voici la traduction d'un article extrait du livre RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 et EX300.

À partir de moi : J'espère que cet article sera utile non seulement aux débutants, mais aussi qu'il aidera des administrateurs plus expérimentés à organiser leurs connaissances.

Alors, c'est parti.

Pour accéder aux fichiers sous Linux, on utilise des permissions. Celles-ci sont assignées à trois entités : le propriétaire du fichier, le propriétaire du groupe et un autre objet (c'est-à-dire tous les autres). Dans cet article, vous apprendrez comment appliquer ces permissions.

L'article commence par un aperçu des concepts de base, suivis d'une discussion sur les permissions spéciales (Special permissions) et les listes de contrôle d'accès (ACL). À la fin de cet article, nous aborderons la configuration des permissions par défaut via umask, ainsi que la gestion des attributs étendus des utilisateurs.

Gestion de la propriété des fichiers

Avant de discuter des permissions, vous devez connaître le rôle du propriétaire d'un fichier et d'un répertoire. La propriété des fichiers et des répertoires est cruciale pour travailler avec les permissions. Dans cette section, vous apprendrez d'abord comment voir le propriétaire. Ensuite, vous apprendrez à changer le propriétaire du groupe et de l'utilisateur pour les fichiers et les répertoires.

Affichage du propriétaire d'un fichier ou d'un répertoire

Sous Linux, chaque fichier et chaque répertoire a deux propriétaires : l'utilisateur et le propriétaire du groupe.

Ces propriétaires sont établis lors de la création d'un fichier ou d'un répertoire. L'utilisateur qui crée un fichier devient le propriétaire de ce fichier, et le groupe principal auquel cet utilisateur appartient devient également le propriétaire de ce fichier. Pour déterminer si vous avez en tant qu'utilisateur les droits d'accès à un fichier ou à un répertoire, le shell vérifie la propriété.

Cela se déroule dans l'ordre suivant :

1. Le shell vérifie si vous êtes le propriétaire du fichier auquel vous souhaitez accéder. Si vous êtes ce propriétaire, vous obtenez les permissions et le shell cesse la vérification.
2. Si vous n'êtes pas le propriétaire du fichier, le shell vérifiera si vous êtes membre du groupe qui a des permissions sur ce fichier. Si vous êtes membre de ce groupe, vous accédez au fichier avec les permissions qui sont établies pour ce groupe, et le shell cessera la vérification.
3. Si vous n'êtes ni utilisateur ni propriétaire du groupe, vous recevrez les droits des autres utilisateurs (Other).

Pour voir les attributions actuelles du propriétaire, vous pouvez utiliser la commande ls -l. Cette commande montre l'utilisateur et le propriétaire du groupe. Vous pouvez voir ci-dessous les paramètres du propriétaire pour les répertoires dans le répertoire /home.

[root@server1 home]# ls -l
total 8
drwx------. 3  bob            bob            74     Feb   6   10:13 bob
drwx------. 3  caroline       caroline       74     Feb   6   10:13 caroline
drwx------. 3  fozia          fozia          74     Feb   6   10:13 fozia
drwx------. 3  lara           lara           74     Feb   6   10:13 lara
drwx------. 5  lisa           lisa           4096   Feb   6   10:12 lisa
drwx------. 14 user           user           4096   Feb   5   10:35 user

Avec la commande ls vous pouvez afficher le propriétaire des fichiers dans ce répertoire. Parfois, il peut être utile d’obtenir une liste de tous les fichiers du système appartenant à un utilisateur ou à un groupe donné. Pour cela, vous pouvez utiliser find. L'argument find -user peut être utilisé à cet effet. Par exemple, la commande suivante montre tous les fichiers dont le propriétaire est l'utilisateur linda :

find / -user linda

Vous pouvez également utiliser find pour rechercher des fichiers dont un groupe spécifique est le propriétaire.

Par exemple, la commande suivante recherche tous les fichiers appartenant au groupe users:

find / -group users

Changement de propriétaire

Pour appliquer les autorisations appropriées, la première chose à considérer est la propriété. Pour cela, il existe la commande chown. La syntaxe de cette commande est simple à comprendre :

chown qui quoi

Par exemple, la commande suivante change le propriétaire du répertoire /home/account en utilisateur linda :

chown linda /home/account

Commande chown a plusieurs options, dont une est particulièrement utile : -R. Vous pouvez deviner ce qu'elle fait, car cette option est également disponible pour de nombreuses autres commandes. Elle vous permet de définir le propriétaire de manière récursive, ce qui vous permet de définir le propriétaire du répertoire actuel et de tout ce qui est en dessous. La commande suivante change le propriétaire du répertoire /home et de tout ce qui se trouve sous celui-ci pour l'utilisateur linda :

Les propriétaires ressemblent maintenant à ceci :

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 account account 62 Sep 25 21:41 account
drwx------. 2 lisa    lisa    62 Sep 25 21:42 lisa

Exécutons :

[root@localhost ~]# chown -R lisa /home/account
[root@localhost ~]#

Maintenant, l'utilisateur lisa est devenu propriétaire du répertoire account :

[root@localhost ~]# ls -l /home
total 0
drwx------. 2 lisa account 62 Sep 25 21:41 account
drwx------. 2 lisa lisa    62 Sep 25 21:42 lisa

Changement de propriétaire du groupe

Il existe deux façons de changer la propriété d'un groupe. Vous pouvez le faire en utilisant chown, mais il existe une commande spéciale appelée chgrp, qui fait ce travail. Si vous souhaitez utiliser la commande chown, utilisez . ou : avant le nom du groupe.

La commande suivante change le propriétaire d'un groupe de /home/account en le groupe account :

chown .account /home/account

Vous pouvez utiliser chown pour changer le propriétaire d'un utilisateur et/ou d'un groupe de plusieurs manières. Voici quelques exemples :

• chown lisa myfile1 définit l'utilisateur lisa comme propriétaire du fichier myfile1.
• chown lisa.sales myfile définit l'utilisateur lisa comme propriétaire du fichier myfile, et définit également le groupe sales comme propriétaire de ce même fichier.
• chown lisa:sales myfile c'est la même chose que la commande précédente.
• chown .sales myfile définit le groupe sales comme propriétaire du fichier myfile sans changer le propriétaire utilisateur.
• chown :sales myfile c'est la même chose que la commande précédente.

Vous pouvez utiliser la commande chgrp, pour changer le propriétaire du groupe. Considérons l'exemple suivant, où vous pouvez avec chgrp définir le groupe sales comme propriétaire du répertoire account :

chgrp .sales /home/account

Comme dans le cas de chown, vous pouvez utiliser l'option -R avec chgrp, et également changer récursivement le propriétaire du groupe.

Comprendre le propriétaire par défaut

Vous avez peut-être remarqué que lorsque l'utilisateur crée un fichier, une propriété par défaut est appliquée.
L'utilisateur qui crée le fichier devient automatiquement le propriétaire de ce fichier, et le groupe principal de cet utilisateur devient automatiquement le propriétaire de ce fichier. Généralement, c'est le groupe indiqué dans le fichier /etc/passwd comme groupe principal de l'utilisateur. Cependant, si l'utilisateur est membre de plusieurs groupes, il peut changer son groupe principal effectif.

Pour afficher le groupe primaire effectif actuel, l'utilisateur peut utiliser la commande groups:

[root@server1 ~]# groups lisa
lisa : lisa account sales

Si l'utilisateur courant linda souhaite changer son groupe primaire effectif, il utilisera la commande newgrp, suivie du nom du groupe qu'il souhaite définir comme nouveau groupe primaire effectif. Après avoir utilisé la commande newgrp le groupe primaire restera actif tant que l'utilisateur n'entrera pas la commande exit ou ne se déconnecte pas.

Voici comment l'utilisateur linda utilise cette commande, où le groupe primaire est devenu le groupe sales :

lisa@server1 ~]$ groups
lisa compte ventes
[lisa@server1 ~]$ newgrp ventes
[lisa@server1 ~]$ groups
ventes lisa compte
[lisa@server1 ~]$ touch fichier1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa ventes 0 6 fév 10:06 fichier1

Après avoir changé le groupe principal actif, tous les nouveaux fichiers créés par l'utilisateur recevront ce groupe comme groupe propriétaire. Pour revenir à la configuration d'origine du groupe principal, utilisez exit.

Pour pouvoir utiliser la commande newgrp, l'utilisateur doit être membre du groupe qu'il souhaite utiliser comme principal. En outre, un mot de passe de groupe peut être utilisé pour le groupe à l'aide de la commande gpasswd. Si l'utilisateur utilise la commande newgrp, mais n'est pas membre du groupe cible, le shell demandera le mot de passe du groupe. Une fois que vous aurez saisi le bon mot de passe de groupe, le nouveau groupe principal effectif sera défini.

Gestion des droits principaux

Le système de permissions Linux a été inventé dans les années 1970. Étant donné que les besoins en informatique étaient limités à cette époque, le système de permissions de base était plutôt restreint. Ce système de permissions utilise trois droits qui peuvent être appliqués aux fichiers et aux répertoires. Dans cette section, vous découvrirez comment utiliser et modifier ces permissions.

Comprendre les droits de lecture, d'écriture et d'exécution

Les trois droits principaux vous permettent de lire, d'écrire et d'exécuter des fichiers. L'effet de ces permissions diffère lorsqu'il est appliqué à des fichiers ou à des répertoires. Quand il s'agit d'un fichier, le droit de lecture vous permet d'ouvrir le fichier pour le lire. Par conséquent, vous pouvez lire son contenu, mais cela signifie que votre ordinateur peut ouvrir le fichier pour en faire quelque chose.

Un fichier programmatique qui nécessite un accès à une bibliothèque doit, par exemple, avoir un accès en lecture à cette bibliothèque. Cela signifie que le droit de lecture est la permission la plus fondamentale dont vous avez besoin pour travailler avec les fichiers.

Concernant un répertoire, la lecture permet d'afficher le contenu de ce répertoire. Vous devez savoir que ce droit ne vous permet pas de lire les fichiers dans le répertoire. Le système de permissions Linux ne connaît pas l'héritage, et la seule façon de lire un fichier est d'utiliser les permissions de lecture pour ce fichier.

Comme vous pouvez probablement le deviner, le droit d'écriture, s'il est appliqué à un fichier, permet d'écrire dans ce fichier. En d'autres termes, il permet de modifier le contenu des fichiers existants. Cependant, il ne permet pas de créer ou de supprimer de nouveaux fichiers ou de modifier les permissions d'accès au fichier. Pour cela, vous devez accorder les droits d'écriture au répertoire où vous souhaitez créer le fichier. Dans les catalogues, ce droit permet également de créer et de supprimer de nouveaux sous-dossiers.

Le droit d'exécution est ce dont vous avez besoin pour exécuter un fichier. Il ne sera jamais accordé par défaut, ce qui rend Linux pratiquement imperméable aux virus. Seule une personne ayant des droits d'écriture sur le répertoire peut appliquer le droit d'exécution.

Voici un résumé de l'utilisation des permissions de base :

Utilisation de chmod

Pour gérer les droits, utilisez la commande chmod. Lors de son utilisation, chmod vous pouvez définir des permissions pour l'utilisateur (user), le groupe (group) et les autres (other). Vous pouvez utiliser cette commande en deux modes : le mode relatif et le mode absolu. En mode absolu, trois chiffres sont utilisés pour définir les permissions principales.

Lors de la configuration des permissions, calculez la valeur nécessaire. Si vous souhaitez accorder la lecture, l'écriture et l'exécution pour l'utilisateur, la lecture et l'exécution pour le groupe, ainsi que la lecture et l'exécution pour les autres dans le fichier /somefile, vous utilisez la commande suivante : chmod:

chmod 755 /somefile

Lorsque vous utilisez chmod de cette manière, toutes les permissions actuelles sont remplacées par celles que vous avez définies.

Si vous souhaitez modifier les permissions par rapport aux permissions actuelles, vous pouvez utiliser chmod en mode relatif. Lors de l'utilisation de chmod en mode relatif, vous travaillez avec trois indicateurs pour indiquer ce que vous souhaitez faire :

1. Tout d'abord, vous indiquez pour qui vous souhaitez modifier les permissions. Pour cela, vous pouvez choisir entre l'utilisateur (u), le groupe (g) et les autres (o).
2. ). Ensuite, vous utilisez un opérateur pour ajouter ou retirer des permissions du mode actuel ou les définir de manière absolue.
3. Enfin, vous utilisez r, w et x, pour indiquer quelles permissions vous souhaitez définir.

Lorsque vous modifiez les autorisations en mode relatif, vous pouvez omettre une partie de « qui », pour ajouter ou supprimer des autorisations pour tous les objets. Par exemple, cette commande ajoute l'autorisation d'exécution pour tous les utilisateurs :

chmod +x somefile

En mode relatif, vous pouvez également utiliser des commandes plus complexes. Par exemple, cette commande ajoute l'autorisation d'écriture pour le groupe et supprime la lecture pour les autres :

chmod g+w,o-r somefile

Lorsque vous utilisez chmod -R o+rx /data vous accordez l'autorisation d'exécution pour tous les répertoires ainsi que pour les fichiers dans le répertoire /data. Pour accorder l'autorisation d'exécution uniquement pour les répertoires et non pour les fichiers, utilisez chmod -R o+ rX /data.

La majuscule X garantit que les fichiers ne recevront pas l'autorisation d'exécution si le fichier n'a pas déjà accordé cette autorisation pour certains objets. Cela rend X une façon plus judicieuse de gérer les autorisations d'exécution ; cela évitera d'accorder cette permission à des fichiers où elle n'est pas nécessaire.

Autorisations étendues

En plus des autorisations de base que vous venez de lire, Linux possède également un ensemble d'autorisations étendues. Ce ne sont pas les permissions que vous définissez par défaut, mais elles fournissent parfois un complément utile. Dans cette section, vous découvrirez ce qu'elles sont et comment les configurer.

Comprendre les autorisations étendues SUID, GUID et sticky bit

Il existe trois autorisations avancées. La première est l'autorisation de définition de l'identificateur utilisateur (SUID). Dans certains cas particuliers, vous pouvez appliquer cette autorisation à des fichiers exécutables. Par défaut, un utilisateur exécutant un fichier exécutable le fait avec ses propres autorisations.

Pour les utilisateurs ordinaires, cela signifie généralement que l'utilisation du programme est limitée. Cependant, dans certains cas, un utilisateur nécessite des autorisations spéciales juste pour accomplir une tâche particulière.

Prenons par exemple une situation où un utilisateur doit changer de mot de passe. Pour cela, l'utilisateur doit écrire son nouveau mot de passe dans le fichier /etc/shadow. Cependant, ce fichier n'est pas accessible en écriture aux utilisateurs sans les droits d'accès root :

root@hnl ~]# ls -l /etc/shadow
----------. 1 root root 1184 Apr 30 16:54 /etc/shadow

L'autorisation SUID offre une solution à ce problème. Dans l'utilitaire /usr/bin/passwd, cette autorisation est appliquée par défaut. Cela signifie que lors du changement de mot de passe, l'utilisateur obtient temporairement les droits root, ce qui lui permet d'écrire dans le fichier /etc/shadow. Vous pouvez voir l'autorisation SUID avec ls -l comment s à l'endroit où vous vous attendez normalement à voir x pour les autorisations utilisateur :

[root@hnl ~]# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32680 Jan 28 2010 /usr/bin/passwd

L'autorisation SUID peut sembler utile (et dans certains cas c'est vrai), mais en même temps elle peut être potentiellement dangereuse. Mal utilisée, vous pourriez accidentellement accorder des droits d'accès root. Je recommande donc de l'utiliser uniquement avec la plus grande prudence.

La plupart des administrateurs n'auront jamais besoin de l'utiliser ; vous ne le verrez que dans certains fichiers où le système d'exploitation doit l'établir par défaut.

La deuxième autorisation spéciale est l'identifiant de groupe (SGID). Cette autorisation a deux effets. Lorsqu'elle est appliquée à un fichier exécutable, elle donne à l'utilisateur qui exécute le fichier les autorisations du propriétaire du groupe de ce fichier. Ainsi, le SGID peut effectuer plus ou moins la même chose que le SUID. Cependant, pour cet objectif, le SGID est pratiquement jamais utilisé.

Comme pour l'autorisation SUID, le SGID est appliqué à certains fichiers système en tant que paramètre par défaut.

Lorsqu'il est appliqué à un répertoire, le SGID peut être utile, car vous pouvez l'utiliser pour définir le propriétaire du groupe par défaut pour les fichiers et sous-répertoires créés dans ce répertoire. Par défaut, lorsque l'utilisateur crée un fichier, son groupe primaire effectif est défini comme le propriétaire du groupe pour ce fichier.

Ce n'est pas toujours très utile, surtout parce que les utilisateurs de Red Hat/CentOS ont comme groupe principal un groupe dont le nom est le même que celui de l'utilisateur, dont l'utilisateur est le seul membre. Ainsi, par défaut, les fichiers créés par l'utilisateur seront des fichiers de groupe pour l'accès général.

Imaginez une situation où les utilisateurs linda et lori travaillent au département de comptabilité et sont membres du groupe account. Par défaut, ces utilisateurs sont membres d'un groupe privé dont ils sont les seuls membres. Cependant, les deux utilisateurs sont également membres du groupe account, mais aussi en tant que paramètre de groupe secondaire.

La situation par défaut est que lorsque l'un de ces utilisateurs crée un fichier, le groupe principal devient le propriétaire. Ainsi, par défaut, linda n'a pas accès aux fichiers créés par lori, et vice versa. Cependant, si vous créez un répertoire partagé de groupe (disons, /groups/account) et assurez-vous que la permission SGID est appliquée à ce répertoire et que le compte de groupe est défini comme propriétaire de groupe pour ce répertoire, tous les fichiers créés dans ce répertoire et dans tous ses sous-répertoires reçoivent également le groupe account comme propriétaire de groupe par défaut.

Pour cette raison, la permission SGID est une autorisation très utile à définir dans les répertoires de groupes partagés.

La permission SGID apparaît dans la sortie ls -l comment s à la position où vous trouvez habituellement la permission d'exécution du groupe :

[root@hnl data]# ls -ld account
drwxr-sr-x. 2 root account 4096 Apr 30 21:28 account

Le troisième des permissions spéciales est le sticky bit. Cette permission est utile pour protéger les fichiers contre la suppression accidentelle dans un environnement où plusieurs utilisateurs ont des droits d'écriture dans le même répertoire. Si le sticky bit est appliqué, un utilisateur peut supprimer un fichier uniquement s'il est le propriétaire du fichier ou du répertoire contenant le fichier. Pour cette raison, il est appliqué par défaut pour le répertoire /tmp et peut également être utile pour les répertoires de groupes partagés.

Sans sticky bit, si un utilisateur peut créer des fichiers dans un répertoire, il peut également supprimer des fichiers de ce répertoire. Dans un environnement de groupe public, cela peut être ennuyeux. Imaginez des utilisateurs comme linda et lori qui ont tous deux des droits d'écriture dans le répertoire /data/account et obtiennent ces permissions grâce à leur participation au groupe account. Ainsi, linda peut supprimer des fichiers créés par lori, et vice versa.

Lorsque vous appliquez le sticky bit, un utilisateur peut supprimer des fichiers seulement si l'une des conditions suivantes est remplie :

• L'utilisateur est le propriétaire du fichier ;
• L'utilisateur est le propriétaire du répertoire dans lequel se trouve le fichier.

Lorsque vous utilisez ls -l, vous pouvez voir le sticky bit comme t à l'endroit où vous voyez généralement les permissions d'exécution pour les autres :

[root@hnl data]# ls -ld account/
drwxr-sr-t. 2 root account 4096 Apr 30 21:28 account/

Application des droits avancés

Pour appliquer SUID, SGID et le sticky bit, vous pouvez également utiliser chmod. SUID a une valeur numérique de 4, SGID a une valeur numérique de 2, et le sticky bit a une valeur numérique de 1.

Si vous souhaitez appliquer ces permissions, vous devez ajouter un argument à quatre chiffres dans chmod, le premier chiffre faisant référence aux permissions spéciales. La ligne suivante, par exemple, ajoutera la permission SGID au répertoire et définira rwx pour l'utilisateur et rx pour le groupe et les autres :

chmod 2755 /somedir

Cela est assez peu pratique si vous devez voir les permissions actuelles qui sont définies avant de travailler avec chmod en mode absolu. (Vous risquez d'écraser les permissions si vous ne le faites pas.) Je recommande donc de travailler en mode relatif si vous devez appliquer l'une des permissions spéciales :

1. Pour SUID, utilisez chmod u+s.
2. Pour SGID, utilisez chmod g+s.
3. Pour le sticky bit, utilisez chmod +t, puis le nom du fichier ou du répertoire pour lequel vous souhaitez définir les permissions.

Le tableau résume tout ce que vous devez savoir sur la gestion des permissions spéciales.

Exemple de travail avec des droits spéciaux

Dans cet exemple, vous utilisez des permissions spéciales pour que les membres du groupe puissent plus facilement partager des fichiers dans le répertoire du groupe commun. Vous attribuez le bit ID du groupe installé, ainsi que le sticky bit, et vous constaterez qu'après leur établissement, des fonctions sont ajoutées pour faciliter la collaboration des membres du groupe.

1. Ouvrez un terminal où vous êtes l'utilisateur linda. Vous pouvez créer un utilisateur avec la commande useradd linda, ajoutez un mot de passe passwd linda.
2. Créez dans le répertoire racine un répertoire /data et un sous-répertoire /data/sales avec la commande mkdir -p /data/sales. Exécutez cd /data/sales, pour aller dans le répertoire sales. Exécutez touch linda1 et touch linda2, pour créer deux fichiers vides dont le propriétaire est linda.
3. Exécutez su — lisa pour passer à l'utilisateur lisa, qui est également membre du groupe sales.
4. Exécutez cd /data/sales et depuis ce répertoire, exécutez ls -l. Vous verrez deux fichiers qui ont été créés par l'utilisateur linda et appartiennent au groupe linda. Exécutez rm -f linda*. Cela supprimera les deux fichiers.
5. Exécutez touch lisa1 et touch lisa2, pour créer deux fichiers qui appartiennent à l'utilisateur lisa.
6. Exécutez su — pour élever vos privilèges au niveau root.
7. Exécutez chmod g+s,o+t /data/sales, pour définir le bit d'identifiant de groupe (GUID), ainsi que le bit sticky dans le répertoire du groupe commun.
8. Exécutez su — linda. Ensuite, exécutez touch linda3 et touch linda4. Vous devriez maintenant voir que les deux fichiers que vous avez créés appartiennent au groupe sales, qui est le propriétaire du groupe du répertoire /data/sales.
9. Exécutez rm -rf lisa*. Le bit sticky empêche la suppression de ces fichiers au nom de l'utilisateur linda, car vous n'êtes pas le propriétaire de ces fichiers. Notez que si l'utilisateur linda est le propriétaire du répertoire /data/sales, il peut de toute façon supprimer ces fichiers !

Gestion des ACL (setfacl, getfacl) sous Linux

Même si les droits étendus discutés ci-dessus ajoutent une fonctionnalité utile à la façon dont Linux gère les autorisations, cela ne vous permet pas d'accorder des autorisations à plus d'un utilisateur ou d'un groupe dans un fichier.

Les listes de contrôle d'accès offrent cette fonctionnalité. De plus, elles permettent aux administrateurs de définir des autorisations par défaut d'une manière complexe, où les autorisations définies peuvent différer d'un répertoire à l'autre.

Comprendre les ACL

Bien que le sous-système ACL ajoute d'excellentes fonctionnalités à votre serveur, il a un inconvénient : toutes les utilitaires ne le supportent pas. Par conséquent, vous risquez de perdre les réglages ACL lors de la copie ou du déplacement de fichiers, et les logiciels de sauvegarde peuvent ne pas effectuer la sauvegarde des réglages ACL.

L'outil tar ne prend pas en charge les ACL. Pour vous assurer que les réglages ACL ne seront pas perdus lors de la création d'une sauvegarde, utilisez star au lieu de tar. star Il fonctionne avec les mêmes paramètres que tar ; il ajoute simplement le support des réglages ACL.

Vous pouvez également faire une sauvegarde des ACL avec getfacl, qui peut être restaurée avec la commande setfacl. Pour créer une sauvegarde, utilisez getfacl -R /directory > file.acls. Pour restaurer les réglages à partir du fichier de sauvegarde, utilisez setfacl —restore=file.acl.

L'absence de support par certains outils ne devrait pas poser problème. Les listes ACL sont souvent appliquées aux répertoires comme mesure structurelle, plutôt qu'aux fichiers individuels.
Par conséquent, il n'y en aura pas beaucoup, seulement quelques-uns appliqués à des emplacements intelligents du système de fichiers. Il est donc relativement facile de restaurer les listes ACL d'origine avec lesquelles vous avez travaillé, même si votre logiciel de sauvegarde ne les prend pas en charge.

Préparation du système de fichiers pour les ACL

Avant de commencer à travailler avec les ACL, il peut être nécessaire de préparer le système de fichiers pour prendre en charge les ACL. Étant donné que les métadonnées du système de fichiers doivent être étendues, le support par défaut pour les ACL n'est pas toujours disponible dans le système de fichiers. Si vous recevez un message « operation not supported » lors de la configuration des listes ACL pour le système de fichiers, il est possible que votre système de fichiers ne prenne pas en charge les ACL.

Pour corriger cela, vous devez ajouter l'option acl mount dans le fichier /etc/fstab, afin que le système de fichiers soit monté avec la prise en charge des ACL par défaut.

Modification et consultation des paramètres ACL avec setfacl et getfacl

Pour définir des ACL, vous avez besoin de la commande setfacl. Pour voir les paramètres ACL actuels, vous avez besoin de getfacl. La commande ls -l ne montre aucune ACL existante ; elle indique simplement + après la liste des autorisations, ce qui indique que les listes ACL s'appliquent également au fichier.

Avant de configurer les listes ACL, il est toujours utile de montrer les paramètres ACL actuels à l'aide de getfacl. Dans l'exemple ci-dessous, vous pouvez voir les droits d'accès actuels, comme montré avec ls -l, ainsi que comme montré avec getfacl. Si vous regardez de suffisamment près, vous verrez que les informations affichées sont exactement les mêmes.

[root@server1 \/]# ls -ld \/dir\ndrwxr-xr-x. 2 root root 6 Feb 6 11:28 \/dir\n[root@server1 \/]# getfacl \/dir\ngetfacl: Removing leading '\/' from absolute path names\n# file: dir\n# owner: root\n# group: root\nuser::rwx\ngroup::r-x\nother::r-x

En conséquence de l'exécution de la commande getfacl il est clair que les autorisations sont affichées pour trois objets différents : utilisateur, groupe et autres. Maintenant, ajoutons une ACL pour donner des droits de lecture et d'exécution au groupe sales. La commande pour cela est setfacl -m g:sales:rx \/dir. Dans cette commande, -m indique que les paramètres ACL actuels doivent être modifiés. Après cela, g:sales:rx indique à la commande de définir une ACL pour la lecture et l'exécution (rx) pour le groupe (g) sales. Vous pouvez voir ci-dessous à quoi ressemble la commande, ainsi que la sortie de la commande getfacl après avoir modifié les paramètres ACL actuels.

[root@server1 \/]# setfacl -m g:sales:rx \/dir\n[root@server1 \/]# getfacl \/dir\ngetfacl: Removing leading '\/' from absolute path names\n# file: dir\n# owner: root\n# group: root\nuser::rwx\ngroup::r-x\ngroup:sales:r-x\nmask::r-x\nother::r-x

Maintenant que vous comprenez comment configurer un ACL de groupe, il est facile de comprendre les ACL pour les utilisateurs et d'autres utilisateurs. Par exemple, la commande setfacl -m u:linda:rwx /data donne des permissions à l'utilisateur linda dans le répertoire /data, sans en faire le propriétaire ni modifier la désignation du propriétaire actuel.

Commande setfacl a de nombreuses fonctionnalités et options. Une option est particulièrement importante, le paramètre -R. Lorsqu'il est utilisé, cette option configure les ACL pour tous les fichiers et sous-répertoires actuellement existants dans le répertoire où vous mettez en place les ACL. Il est recommandé d'utiliser cette option chaque fois que vous modifiez les listes ACL pour des répertoires existants.

Travailler avec l'ACL par défaut

L'un des avantages de l'utilisation des listes ACL est que vous pouvez donner des permissions à plusieurs utilisateurs ou groupes dans un répertoire. Un autre avantage est que vous pouvez inclure l'héritage en travaillant avec l'ACL par défaut.

En configurant l'ACL par défaut, vous définissez les permissions qui seront appliquées à tous les nouveaux éléments créés dans le répertoire. Gardez à l'esprit que l'ACL par défaut ne modifie pas les permissions pour les fichiers et sous-répertoires existants. Pour les modifier, vous devez également ajouter un ACL normal!

C'est important à savoir. Si vous souhaitez utiliser les ACL pour gérer l'accès de plusieurs utilisateurs ou groupes à un même répertoire, vous devez configurer les ACL deux fois. Commencez par utiliser setfacl -R -m, pour modifier les ACL des fichiers actuels. Ensuite, utilisez setfacl -m d:, pour s'occuper de tous les nouveaux éléments qui seront également créés.

Pour configurer l'ACL par défaut, vous devez simplement ajouter l'option d après l'option -m (l'ordre est important!). Par conséquent, utilisez setfacl -m d:g:sales:rx /data, si vous souhaitez que le groupe des ventes puisse lire et exécuter tout ce qui sera jamais créé dans le répertoire /data.

Lors de l'utilisation des listes ACL par défaut, il peut également être utile de configurer des ACL pour d'autres. En général, cela n'a pas beaucoup de sens, car vous pouvez également modifier les permissions pour d'autres en utilisant chmod. Cependant, ce que vous ne pouvez pas faire avec chmod, il s'agit de spécifier les droits qui doivent être accordés à d'autres utilisateurs pour chaque nouveau fichier qui sera créé. Si vous souhaitez que personne n'ait de droits sur quoi que ce soit créé dans /data, par exemple, utilisez setfacl -m d:o::- /data.

Les ACL et les autorisations classiques ne sont pas toujours bien intégrées. Des problèmes peuvent survenir si vous avez appliqué des ACL par défaut à un répertoire, après quoi des éléments ont été ajoutés à ce répertoire, puis que vous essayez de modifier les autorisations classiques. Les modifications appliquées aux autorisations classiques ne seront pas bien reflétées dans l'examen des ACL. Pour éviter les problèmes, définissez d'abord les autorisations classiques, puis, établissez les ACL par défaut (et ensuite, évitez de les modifier à nouveau).

Exemple de gestion des droits étendus à l'aide des ACL

Dans cet exemple, vous continuerez à travailler avec les répertoires /data/account et /data/sales que vous avez créés précédemment. Dans les exemples précédents, vous aviez garanti que le groupe sales avait des permissions sur /data/sales, tandis que le groupe account avait des autorisations sur /data/account.

Tout d'abord, assurez-vous que le groupe account reçoit des autorisations de lecture dans le répertoire /data/sales, tandis que le groupe sales obtient des autorisations de lecture dans le répertoire /data/account.

Ensuite, vous définissez des listes ACL par défaut pour vous assurer que tous les nouveaux fichiers ont les bonnes autorisations pour tous les nouveaux éléments.

1. Ouvrez le terminal.
2. Exécutez setfacl -m g:account:rx /data/sales et setfacl -m g:sales:rx /data/account.
3. Exécutez getfacl, pour vous assurer que les droits d'accès ont été définis comme vous le souhaitiez.
4. Exécutez setfacl -m d:g:account:rwx,g:sales:rx /data/sales, pour définir les ACL par défaut pour le répertoire sales.
5. Ajoutez des ACL par défaut pour le répertoire /data/account, en utilisant setfacl -m d:g:sales:rwx,g:account:rx /data/account.
6. Assurez-vous que les paramètres ACL sont effectifs en ajoutant un nouveau fichier dans /data/sales. Exécutez touch /data/sales/newfile et exécutez getfacl /data/sales/newfile pour vérifier les autorisations actuelles.

Définir les droits par défaut avec umask

Ci-dessus, vous avez appris à travailler avec des ACL par défaut. Si vous n'utilisez pas d'ACL, il existe un paramètre de shell qui définit les autorisations par défaut que vous obtiendrez : umask (masque inversé). Dans cette section, vous apprendrez à modifier les autorisations par défaut à l'aide de umask.

Vous avez probablement remarqué que certaines autorisations par défaut sont définies lorsque vous créez un nouveau fichier. Ces autorisations sont déterminées par le paramètre umask. Ce paramètre d'interface s'applique à tous les utilisateurs lors de la connexion au système. Dans ce paramètre umask une valeur numérique est utilisée, qui est soustraite des permissions maximales qui peuvent être automatiquement définies pour un fichier; la configuration maximale pour les fichiers est 666 et pour les répertoires, 777.

Cependant, certaines exceptions s'appliquent à cette règle. Vous pouvez trouver un aperçu complet des paramètres umask dans le tableau ci-dessous.

Des chiffres, utilisés dans umask, comme pour les arguments numériques de la commande chmod, le premier chiffre correspond aux permissions de l'utilisateur, le deuxième chiffre correspond aux permissions du groupe, et le dernier correspond aux permissions par défaut définies pour les autres. La valeur umask par défaut 022 donne 644 pour tous les nouveaux fichiers et 755 pour tous les nouveaux répertoires créés sur votre serveur.

Un aperçu complet de toutes les valeurs numériques umask et de leurs résultats dans le tableau ci-dessous.

Une manière simple de voir comment fonctionne le paramètre umask est la suivante : commencez avec les permissions par défaut pour un fichier, réglées à 666, et soustrayez umask pour obtenir les permissions effectives. Faites de même pour un répertoire et ses permissions par défaut 777.

Il existe deux façons de modifier le paramètre umask : pour tous les utilisateurs et pour des utilisateurs spécifiques. Si vous souhaitez définir umask pour tous les utilisateurs, vous devez vous assurer que le paramètre umask est pris en compte lors de l'exécution des fichiers d'environnement de shell, comme indiqué dans /etc/profile. L'approche correcte consiste à créer un script de shell nommé umask.sh dans le répertoire /etc/profile.d et d'indiquer umask que vous souhaitez utiliser dans ce script de shell. Si umask est modifié dans ce fichier, il s'applique à tous les utilisateurs après leur connexion au serveur.

Une alternative à la configuration de umask via /etc/profile et les fichiers associés, où il s'applique à tous les utilisateurs qui se connectent, est de modifier les paramètres umask dans un fichier nommé .profile, qui est créé dans le répertoire personnel de chaque utilisateur.

Les paramètres appliqués dans ce fichier ne s'appliquent qu'à un utilisateur spécifique; par conséquent, c'est une bonne méthode si vous avez besoin de plus de détails. Personnellement, j'aime cette fonction pour changer la valeur umask par défaut pour l'utilisateur root à 027, tandis que les utilisateurs ordinaires fonctionnent avec umask par défaut 022.

Travailler avec des attributs utilisateurs étendus

C'est la section finale sur les autorisations dans Linux.

Lors de la gestion des permissions, il existe toujours un lien entre l'objet utilisateur ou le groupe et les permissions que ces objets utilisateur ou groupe ont pour un fichier ou un répertoire. Une méthode alternative pour protéger les fichiers sur un serveur Linux est de travailler avec des attributs.
Les attributs fonctionnent indépendamment de l'utilisateur qui accède au fichier.

Comme pour les ACL, des options peuvent être nécessaires pour les attributs de fichier. mount.

C'est une option user_xattr. Si vous recevez le message « operation not supported » lors de la gestion des attributs utilisateurs étendus, assurez-vous d'avoir défini l'option mount dans le fichier /etc/fstab.

De nombreux attributs sont documentés. Certains attributs sont disponibles, mais ne sont pas encore implémentés. Ne les utilisez pas ; ils ne vous apporteront rien.

Voici les attributs les plus utiles que vous pouvez appliquer :

A Cet attribut garantit que le temps d'accès au fichier n'est pas modifié.
Normalement, chaque fois qu'un fichier est ouvert, le temps d'accès doit être enregistré dans les métadonnées du fichier. Cela affecte négativement les performances ; donc pour les fichiers fréquemment accédés, l'attribut A peut être utilisé pour désactiver cette fonctionnalité.

a Cet attribut permet d'ajouter, mais pas de supprimer un fichier.

c Si vous utilisez un système de fichiers qui prend en charge la compression au niveau du volume, cet attribut garantit que le fichier sera compressé lors de la première activation du mécanisme de compression.

D Cet attribut garantit que les modifications des fichiers sont écrites sur le disque immédiatement, plutôt que d'abord mises en cache. C'est un attribut utile pour les fichiers de base de données critiques, garantissant qu'ils ne sont pas perdus entre le cache de fichiers et le disque dur.

d Cet attribut garantit que le fichier ne sera pas sauvegardé dans les sauvegardes effectuées avec l'outil de sauvegarde.

I Cet attribut active l'indexation pour le répertoire dans lequel il est activé. Cela permet un accès plus rapide aux fichiers pour des systèmes de fichiers primitifs, comme Ext3, qui n'utilisent pas de base de données B-tree pour un accès rapide aux fichiers.

i Cet attribut rend le fichier immuable. Par conséquent, le fichier ne peut pas être modifié, ce qui est utile pour les fichiers qui nécessitent une protection supplémentaire.

j Cet attribut garantit que, dans le système de fichiers ext3, le fichier est d'abord enregistré dans le journal, puis dans les blocs de données sur le disque dur.

s Écrire les blocs dans lesquels le fichier a été enregistré avec des zéros après la suppression du fichier. Cela garantit qu'il est impossible de récupérer le fichier après sa suppression.

u Cet attribut conserve des informations sur la suppression. Cela permet de développer un utilitaire qui fonctionne avec ces informations pour récupérer les fichiers supprimés.

Si vous souhaitez appliquer des attributs, vous pouvez utiliser la commande chattr. Par exemple, utilisez chattr +s somefile, pour appliquer les attributs à somefile. Vous souhaitez supprimer l'attribut ? Utilisez donc chattr -s somefile, et il sera supprimé. Pour obtenir un aperçu de tous les attributs actuellement appliqués, utilisez la commande lsattr.

Résumé

Dans cet article, vous avez appris comment travailler avec les permissions. Vous avez lu sur les trois permissions de base, les permissions étendues et comment appliquer des listes ACL dans le système de fichiers. Vous avez également appris comment utiliser le paramètre umask pour appliquer les permissions par défaut. À la fin de cet article, vous avez découvert comment utiliser des attributs utilisateur étendus pour ajouter un niveau de sécurité supplémentaire au système de fichiers.

Si vous avez apprécié cette traduction, n'hésitez pas à le faire savoir dans les commentaires. Cela me donnera plus de motivation pour faire des traductions utiles.

Dans cet article, j'ai corrigé quelques fautes de frappe et erreurs grammaticales. J'ai réduit certains paragraphes encombrants en plus petits pour une meilleure lisibilité.

Au lieu de « Seule une personne ayant des droits administratifs sur le répertoire peut appliquer la permission d'exécution. » j'ai corrigé en « Seule une personne ayant des droits d'écriture sur le répertoire peut appliquer la permission d'exécution. », ce qui est plus correct.

Merci pour vos remarques berez.

Remplacé :
Si vous n'êtes pas le propriétaire de l'utilisateur, le shell vérifiera si vous êtes membre du groupe qui porte également le nom du groupe de fichiers.

En :
Si vous n'êtes pas le propriétaire du fichier, le shell vérifiera si vous êtes membre du groupe qui a des permissions sur ce fichier. Si vous êtes membre de ce groupe, vous accédez au fichier avec les permissions qui sont établies pour ce groupe, et le shell cessera la vérification.

Merci pour la remarque CryptoPirate

Source : habr.com