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

Salut tout le monde. Ceci est une traduction d'un article du livre RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 et EX300.

De moi-même: J'espère que l'article sera utile non seulement aux débutants, mais aidera également les administrateurs plus expérimentés à rationaliser leurs connaissances.

Alors, allons-y.

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

Pour accéder aux fichiers sous Linux, des autorisations sont utilisées. Ces autorisations sont attribuées à trois objets : 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 à appliquer des autorisations.

Cet article commence par un aperçu des concepts de base, suivi d'une discussion sur les autorisations spéciales et les listes de contrôle d'accès (ACL). À la fin de cet article, nous couvrons la définition des autorisations par défaut via umask, ainsi que la gestion des attributs utilisateur étendus.

Gestion de la propriété des fichiers

Avant de discuter des autorisations, vous devez connaître le rôle du propriétaire du fichier et du répertoire. La propriété des fichiers et des répertoires est essentielle pour gérer les autorisations. Dans cette section, vous apprendrez d'abord comment vous pouvez voir le propriétaire. Vous apprendrez ensuite à modifier le propriétaire et l'utilisateur du groupe 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 : un utilisateur et un propriétaire de groupe.

Ces propriétaires sont définis lors de la création d'un fichier ou d'un répertoire. L'utilisateur qui crée le fichier devient le propriétaire de ce fichier, et le groupe principal auquel appartient le même utilisateur devient également le propriétaire de ce fichier. Pour déterminer si vous, en tant qu'utilisateur, avez l'autorisation d'accéder à un fichier ou à un répertoire, le shell vérifie la propriété.

Cela se produit 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 le propriétaire, vous obtenez des autorisations et le shell arrête de vérifier.
  2. Si vous n'êtes pas le propriétaire du fichier, le shell vérifiera si vous êtes membre d'un groupe disposant d'autorisations sur le fichier. Si vous êtes membre de ce groupe, vous accéderez au fichier avec les autorisations définies par le groupe et le shell arrêtera la vérification.
  3. Si vous n'êtes ni un utilisateur ni le propriétaire d'un groupe, vous disposez des droits des autres utilisateurs (Autre).

Pour voir les affectations actuelles du propriétaire, vous pouvez utiliser la commande ls -l. Cette commande affiche l'utilisateur et le propriétaire du groupe. Ci-dessous, vous pouvez voir 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

Utilisation de la commande ls vous pouvez afficher le propriétaire des fichiers dans un répertoire donné. Parfois, il peut être utile d'obtenir une liste de tous les fichiers du système dont le propriétaire est un utilisateur ou un groupe donné. Pour cela, vous pouvez utiliser trouver. Argument trouver-utilisateur peut être utilisé à cette fin. Par exemple, la commande suivante répertorie tous les fichiers appartenant à l'utilisateur linda :

find / -user linda

также можете использовать trouver pour rechercher des fichiers qui ont un certain groupe comme propriétaire.

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

find / -group users

Changement de propriétaire

Pour appliquer les autorisations appropriées, la première chose à considérer est la propriété. Il y a une commande pour ça chown. La syntaxe de cette commande est facile à comprendre :

chown кто что

Par exemple, la commande suivante remplace le propriétaire du répertoire /home/account par l'utilisateur linda :

chown linda /home/account

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

Maintenant, les propriétaires ressemblent à 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

Faisons:

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

L'utilisateur lisa est désormais propriétaire du répertoire des comptes :

[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

Changer le propriétaire d'un groupe

Il existe deux manières de modifier la propriété d'un groupe. Vous pouvez le faire en utilisant chown, mais il existe une commande spéciale nommée chgrpça fait le boulot. Si vous souhaitez utiliser la commande chown, utilisation . ou : devant le nom du groupe.

La commande suivante remplace tout propriétaire du groupe /home/account par le groupe de comptes :

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 monfichier1 définit l'utilisateur lisa comme propriétaire de myfile1.
  • chown lisa.sales monfichier définit l'utilisateur lisa comme propriétaire du fichier monfichier et définit également le groupe de ventes comme propriétaire du même fichier.
  • chown lisa:sales monfichier identique à la commande précédente.
  • chown .sales monfichier définit le groupe de ventes comme propriétaire de monfichier sans modifier le propriétaire de l'utilisateur.
  • chown :sales monfichier identique à la commande précédente.

Vous pouvez utiliser la commande chgrppour changer le propriétaire du groupe. Prenons l'exemple suivant, où vous pouvez utiliser chgrp définissez le propriétaire du répertoire de compte sur le groupe de ventes :

chgrp .sales /home/account

Comme dans le cas de chown, vous pouvez utiliser l'option -R с chgrp, ainsi que le changement récursif du propriétaire du groupe.

Comprendre le propriétaire par défaut

Vous avez peut-être remarqué que lorsqu'un utilisateur crée un fichier, la 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. Il s'agit généralement du groupe répertorié dans le fichier /etc/passwd en tant que groupe principal de l'utilisateur. Toutefois, si l'utilisateur est membre de plusieurs groupes, il peut modifier le groupe principal effectif.

Pour afficher le groupe principal effectif actuel, l'utilisateur peut utiliser la commande groupes:

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

Si l'utilisateur actuel de linda veut changer le groupe principal effectif, il utilisera la commande nouveaugrpsuivi du nom du groupe qu'il souhaite définir comme nouveau groupe principal effectif. Après avoir utilisé la commande nouveaugrp le groupe principal sera actif jusqu'à ce que l'utilisateur entre une commande sortie ou ne pas se déconnecter.

Ce qui suit montre comment l'utilisateur linda utilise cette commande, avec sales comme groupe principal :

lisa@server1 ~]$ groups
lisa account sales
[lisa@server1 ~]$ newgrp sales
[lisa@server1 ~]$ groups
sales lisa account
[lisa@server1 ~]$ touch file1
[lisa@server1 ~]$ ls -l
total 0
-rw-r--r--. 1 lisa sales 0 Feb 6 10:06 file1

Après avoir modifié le groupe principal effectif, tous les nouveaux fichiers créés par l'utilisateur auront ce groupe comme propriétaire du groupe. Pour rétablir le paramètre de groupe principal d'origine, utilisez sortie.

Pour pouvoir utiliser la commande nouveaugrp, l'utilisateur doit être membre du groupe qu'il souhaite utiliser comme groupe principal. De plus, un mot de passe de groupe peut être utilisé pour un groupe à l'aide de la commande gpasswd. Si l'utilisateur utilise la commande nouveaugrpmais n'est pas membre du groupe cible, le shell demande le mot de passe du groupe. Après avoir saisi le mot de passe de groupe correct, un nouveau groupe principal effectif sera créé.

Gestion des droits fondamentaux

Le système d'autorisation Linux a été inventé dans les années 1970. Étant donné que les besoins informatiques étaient limités à cette époque, le système d'autorisation de base était assez limité. Ce système d'autorisation utilise trois autorisations qui peuvent être appliquées aux fichiers et aux répertoires. Dans cette section, vous apprendrez à utiliser et à modifier ces autorisations.

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

Trois autorisations de base vous permettent de lire, d'écrire et d'exécuter des fichiers. L'effet de ces autorisations diffère lorsqu'elles sont appliquées à des fichiers ou des répertoires. Pour un fichier, l'autorisation de lecture vous donne le droit d'ouvrir le fichier en lecture. 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 de programme qui a besoin d'accéder à une bibliothèque doit, par exemple, avoir un accès en lecture à cette bibliothèque. Il s'ensuit que l'autorisation de lecture est l'autorisation la plus élémentaire dont vous avez besoin pour travailler avec des fichiers.

Appliquée à un répertoire, la lecture permet d'afficher le contenu de ce répertoire. Vous devez savoir que cette autorisation ne vous permet pas de lire les fichiers du répertoire. Le système d'autorisation Linux ne connaît pas l'héritage, et la seule façon de lire un fichier est d'utiliser les autorisations de lecture sur ce fichier.

Comme vous pouvez probablement le deviner, l'autorisation d'écriture, si elle est appliquée à un fichier, permet d'écrire dans le fichier. En d'autres termes, il vous permet de modifier le contenu des fichiers existants. Cependant, il ne vous permet pas de créer ou de supprimer de nouveaux fichiers ou de modifier les autorisations de fichiers. Pour ce faire, vous devez donner une autorisation en écriture au répertoire dans lequel vous souhaitez créer le fichier. Dans les répertoires, cette autorisation vous permet également de créer et de supprimer de nouveaux sous-répertoires.

L'autorisation d'exécution est ce dont vous avez besoin pour exécuter le fichier. Il ne sera jamais installé par défaut, ce qui rend Linux presque complètement immunisé contre les virus. Seule une personne disposant d'autorisations d'écriture sur le répertoire peut appliquer l'autorisation d'exécution.

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

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

Utilisation de chmod

La commande est utilisée pour gérer les autorisations. chmod... À l'aide de chmod vous pouvez définir des autorisations pour l'utilisateur (user), les groupes (group) et les autres (other). Vous pouvez utiliser cette commande dans deux modes : mode relatif et mode absolu. En mode absolu, trois chiffres sont utilisés pour définir les autorisations de base.

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

Lors de la définition des autorisations, calculez la valeur dont vous avez besoin. Si vous souhaitez définir la lecture/écriture/exécution pour l'utilisateur, la lecture/exécution pour le groupe et la lecture/exécution pour les autres dans /somefile, utilisez la commande suivante chmod:

chmod 755 /somefile

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

Si vous souhaitez modifier les autorisations relatives aux autorisations actuelles, vous pouvez utiliser chmod en mode relatif. En utilisant chmod en mode relatif vous travaillez avec trois indicateurs pour indiquer ce que vous voulez faire :

  1. D'abord, vous spécifiez pour qui vous souhaitez modifier les autorisations. Pour ce faire, vous pouvez choisir entre utilisateur (u), groupe (g) et d'autres (o).
  2. Vous utilisez ensuite une instruction pour ajouter ou supprimer des autorisations du mode actuel, ou les définir de manière absolue.
  3. À la fin, vous utilisez r, w и xpour spécifier les autorisations que vous souhaitez définir.

Lors de la modification des autorisations en mode relatif, vous pouvez ignorer la partie "à" pour ajouter ou supprimer l'autorisation pour tous les objets. Par exemple, cette commande ajoute une autorisation d'exécution pour tous les utilisateurs :

chmod +x somefile

Lorsque vous travaillez en mode relatif, vous pouvez également utiliser des commandes plus complexes. Par exemple, cette commande ajoute l'autorisation d'écriture à un groupe et supprime l'autorisation de lecture pour les autres :

chmod g+w,o-r somefile

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

Le X majuscule garantit que les fichiers n'obtiennent pas l'autorisation d'exécution à moins que le fichier n'ait déjà défini l'autorisation d'exécution pour certains objets. Cela fait de X un moyen plus intelligent de gérer les autorisations d'exécution ; cela évitera de définir cette autorisation sur des fichiers où elle n'est pas requise.

Droits étendus

En plus des autorisations de base que vous venez de lire, Linux dispose également d'un ensemble d'autorisations avancées. Ce ne sont pas les autorisations que vous définissez par défaut, mais elles fournissent parfois un ajout utile. Dans cette section, vous apprendrez ce qu'ils sont et comment les configurer.

Présentation des autorisations étendues SUID, GUID et Sticky Bit

Il existe trois autorisations avancées. Le premier d'entre eux est l'autorisation de définir un identifiant d'utilisateur (SUID). Dans certains cas particuliers, vous pouvez appliquer cette autorisation aux fichiers exécutables. Par défaut, un utilisateur qui exécute un exécutable exécute ce fichier 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, l'utilisateur a besoin d'autorisations spéciales, uniquement pour effectuer une tâche spécifique.

Considérons, par exemple, une situation où un utilisateur doit changer son mot de passe. Pour ce faire, l'utilisateur doit écrire son nouveau mot de passe dans le fichier /etc/shadow. Cependant, ce fichier n'est pas accessible en écriture par les utilisateurs non root :

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

La permission SUID offre une solution à ce problème. L'utilitaire /usr/bin/passwd utilise cette autorisation par défaut. Cela signifie que lors du changement de mot de passe, l'utilisateur devient temporairement root, ce qui lui permet d'écrire dans le fichier /etc/shadow. Vous pouvez voir la permission SUID avec ls -l comme s dans une position où l'on s'attend normalement à voir x pour les autorisations personnalisées :

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

La permission SUID peut sembler utile (et dans certains cas, elle l'est), mais en même temps, elle est potentiellement dangereuse. S'il n'est pas appliqué correctement, vous pouvez accidentellement donner des autorisations root. Par conséquent, je recommande de ne l'utiliser qu'avec le plus grand soin.

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 devrait le définir par défaut.

La deuxième autorisation spéciale est l'identifiant de groupe (SGID). Cette autorisation a deux effets. Lorsqu'il est appliqué à un fichier exécutable, il donne à l'utilisateur qui exécute le fichier les autorisations du propriétaire du groupe du fichier. Donc SGID peut faire plus ou moins la même chose que SUID. Cependant, SGID n'est pratiquement pas utilisé à cette fin.

Comme pour l'autorisation SUID, 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 de groupe par défaut pour les fichiers et les sous-répertoires créés dans ce répertoire. Par défaut, lorsqu'un utilisateur crée un fichier, son groupe principal effectif est défini comme propriétaire du groupe pour ce fichier.

Ce n'est pas toujours très utile, d'autant plus que les utilisateurs de Red Hat/CentOS ont leur groupe principal défini sur un groupe portant le même nom que l'utilisateur et dont l'utilisateur est le seul membre. Ainsi, par défaut, les fichiers créés par l'utilisateur seront partagés en masse.

Imaginez une situation où les utilisateurs linda et lori travaillent dans la comptabilité et sont membres d'un groupe Compte. Par défaut, ces utilisateurs sont membres d'un groupe privé dont ils sont le seul membre. Cependant, les deux utilisateurs sont membres du groupe de comptes, mais également 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 en devient le propriétaire. Par conséquent, par défaut, linda ne peut pas accéder aux fichiers créés par lori, et vice versa. Cependant, si vous créez un répertoire de groupe partagé (disons /groups/account) et assurez-vous que l'autorisation SGID est appliquée à ce répertoire et que le compte de groupe est défini comme propriétaire du groupe pour ce répertoire, tous les fichiers créés dans ce répertoire et tous de ses sous-répertoires, obtenez également le compte de groupe en tant que propriétaire du groupe par défaut.

Pour cette raison, l'autorisation SGID est une autorisation très utile à définir sur les répertoires de groupes publics.

Autorisation SGID affichée dans la sortie ls -l comme s à la position où vous trouveriez normalement la permission d'exécuter un groupe :

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

La troisième des autorisations spéciales est la partie collante. Cette autorisation est utile pour protéger les fichiers d'une suppression accidentelle dans un environnement où plusieurs utilisateurs ont un accès en écriture au même répertoire. Si un sticky bit est utilisé, un utilisateur ne peut supprimer un fichier que s'il est l'utilisateur propriétaire du fichier ou du répertoire qui contient le fichier. Pour cette raison, il est utilisé comme autorisation par défaut pour le répertoire /tmp et peut également être utile pour les répertoires de groupes publics.

Sans le sticky bit, si l'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 les utilisateurs linda et lori, qui ont tous deux des autorisations d'écriture sur le répertoire /data/account et obtiennent ces autorisations en étant membres du groupe de comptes. Par conséquent, linda peut supprimer les fichiers créés par lori et vice versa.

Lorsque vous appliquez le sticky bit, l'utilisateur ne peut supprimer des fichiers que si l'une des conditions suivantes est vraie :

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

Lorsque vous utilisez le ls -l, vous pouvez voir le morceau collant comme t dans la position où vous verriez normalement l'autorisation 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 étendus

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

Si vous souhaitez appliquer ces autorisations, vous devez ajouter un argument à quatre chiffres à chmod, dont le premier chiffre fait référence à des autorisations spéciales. La ligne suivante, par exemple, ajoutera l'autorisation SGID au répertoire et définira rwx pour l'utilisateur et rx pour le groupe et autres :

chmod 2755 /somedir

Ceci est plutôt peu pratique si vous avez besoin de voir les autorisations actuelles qui sont définies avant de travailler avec chmod en mode absolu. (Vous courez le risque d'écraser les autorisations si vous ne le faites pas.) Je vous recommande donc d'exécuter en mode relatif si vous devez appliquer l'une des autorisations spéciales :

  1. Pour une utilisation SUID chmod u+s.
  2. Pour une utilisation SGID chmod g+s.
  3. Pour une utilisation collante chmod +t, suivi du nom du fichier ou du répertoire pour lequel vous souhaitez définir des autorisations.

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

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

Exemple de travail avec des droits spéciaux

Dans cet exemple, vous utilisez des autorisations spéciales pour permettre aux membres du groupe de partager plus facilement des fichiers dans le répertoire de groupe partagé. Vous attribuez le bit ID à l'ID de groupe défini ainsi qu'au bit collant, et vous voyez qu'une fois qu'ils sont définis, des fonctionnalités 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 utilisateurajouter linda, ajouter un mot de passe mot de passe linda.
  2. Créez le répertoire /data à la racine et le sous-répertoire /data/sales avec la commande mkdir -p /données/ventes. Complet cd /données/ventespour accéder au répertoire des ventes. Complet toucher linda1 и toucher linda2pour créer deux fichiers vides appartenant à linda.
  3. Exécuter su-lisa pour faire passer l'utilisateur actuel à l'utilisateur lisa, qui est également membre du groupe de vente.
  4. Exécuter cd /données/ventes et à partir de ce répertoire, exécutez ls -l. Vous verrez deux fichiers créés par l'utilisateur linda et appartenant au groupe linda. Complet rm -f linda*. Cela supprimera les deux fichiers.
  5. Exécuter toucher lisa1 и toucher lisa2pour créer deux fichiers appartenant à l'utilisateur lisa.
  6. Exécuter su- pour élever vos privilèges à root.
  7. Exécuter chmod g+s,o+t /données/ventespour définir le bit d'identificateur de groupe (GUID) ainsi que le bit collant dans le répertoire de groupe partagé.
  8. Exécuter su-linda. Alors fais toucher linda3 и toucher linda4. Vous devriez maintenant voir que les deux fichiers que vous avez créés appartiennent au groupe sales, qui est le groupe propriétaire du répertoire /data/sales.
  9. Exécuter rm -rf lisa*. Le sticky bit empêche la suppression de ces fichiers au nom de l'utilisateur linda, puisque 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 quand même supprimer ces fichiers !

Gestion des ACL (setfacl, getfacl) sous Linux

Même si les autorisations étendues décrites ci-dessus ajoutent des fonctionnalités utiles à la façon dont Linux gère les autorisations, cela ne vous permet pas d'accorder des autorisations à plusieurs utilisateurs ou groupes dans le même fichier.

Les listes de contrôle d'accès offrent cette fonctionnalité. En outre, ils permettent aux administrateurs de définir des autorisations par défaut de manière complexe, les autorisations définies pouvant varier d'un répertoire à l'autre.

Comprendre les ACL

Bien que le sous-système ACL ajoute de grandes fonctionnalités à votre serveur, il présente un inconvénient : tous les utilitaires ne le prennent pas en charge. Par conséquent, vous risquez de perdre vos paramètres ACL lorsque vous copiez ou déplacez des fichiers, et votre logiciel de sauvegarde peut ne pas sauvegarder vos paramètres ACL.

L'utilitaire tar ne prend pas en charge les ACL. Pour vous assurer que les paramètres ACL ne sont pas perdus lorsque vous créez une sauvegarde, utilisez étoile au lieu de goudron. étoile fonctionne avec les mêmes options que tar ; il ajoute simplement la prise en charge des paramètres ACL.

Vous pouvez également sauvegarder les ACL avec getfacl, qui peut être restauré à l'aide de la commande setfacl. Pour créer une sauvegarde, utilisez getfacl -R /répertoire > fichier.acls. Pour restaurer les paramètres à partir d'un fichier de sauvegarde, utilisez setfacl --restore=fichier.acl.

Le manque de support par certains outils ne devrait pas être un problème. Les ACL sont souvent appliquées aux répertoires en tant que mesure structurelle plutôt qu'aux fichiers individuels.
Par conséquent, il n'y en aura pas beaucoup, mais seulement quelques-uns, appliqués à des endroits intelligents du système de fichiers. Par conséquent, la restauration des ACL d'origine avec lesquelles vous avez travaillé est relativement simple, 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, vous devrez peut-être préparer votre 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, il n'y a pas toujours de prise en charge par défaut des ACL dans le système de fichiers. Si vous obtenez un message "opération non prise en charge" lors de la configuration des ACL pour un système de fichiers, votre système de fichiers peut ne pas prendre en charge les ACL.

Pour résoudre ce problème, vous devez ajouter l'option montage ACL dans /etc/fstab afin que le système de fichiers soit monté avec le support ACL par défaut.

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

Pour définir une ACL, vous avez besoin de la commande setfacl. Pour voir les paramètres ACL actuels, vous devez getfacl. Équipe ls -l n'affiche aucune liste de contrôle d'accès existante ; il affiche simplement un + après la liste des autorisations, ce qui indique que les ACL s'appliquent également au fichier.

Avant de configurer les ACL, il est toujours conseillé d'afficher les paramètres ACL actuels avec getfacl. Dans l'exemple ci-dessous, vous pouvez voir les autorisations actuelles, comme indiqué avec ls -l, et aussi comme indiqué avec getfacl. Si vous regardez d'assez près, vous verrez que les informations affichées sont exactement les mêmes.

[root@server1 /]# ls -ld /dir
drwxr-xr-x. 2 root root 6 Feb 6 11:28 /dir
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Suite à l'exécution de la commande getfacl ci-dessous, vous pouvez voir que les autorisations sont affichées pour trois objets différents : utilisateur, groupe et autres. Ajoutons maintenant une liste de contrôle d'accès pour donner également des autorisations de lecture et d'exécution au groupe de ventes. commande pour cela setfacl -mg:sales:rx /dir. Dans cette équipe -m indique que les paramètres ACL actuels doivent être modifiés. Après cela g:ventes:rx indique à la commande de définir l'ACL en lecture-exécution (rx) pour le groupe (g) ventes. Ci-dessous, vous pouvez voir à 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
[root@server1 /]# getfacl /dir
getfacl: Removing leading '/' from absolute path names
# file: dir
# owner: root
# group: root
user::rwx
group::r-x
group:sales:r-x
mask::r-x
other::r-x

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

Équipe setfacl a de nombreuses fonctionnalités et options. Une option est particulièrement importante, le paramètre -R. Si elle est utilisée, l'option établit le paramètre ACL pour tous les fichiers et sous-répertoires qui existent actuellement dans le répertoire où vous avez défini l'ACL. Il est recommandé de toujours utiliser cette option lors de la modification des ACL pour les répertoires existants.

Utilisation des ACL par défaut

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

En définissant l'ACL par défaut, vous déterminez les autorisations qui seront définies pour tous les nouveaux éléments créés dans le répertoire. Sachez que l'ACL par défaut ne modifie pas les autorisations sur les fichiers et sous-répertoires existants. Pour les changer, vous devez également ajouter une ACL normale !

Ceci est important à savoir. Si vous souhaitez utiliser une ACL pour configurer plusieurs utilisateurs ou groupes pour accéder au même répertoire, vous devez définir l'ACL deux fois. Première utilisation setfacl -R -mpour modifier l'ACL des fichiers en cours. Utilisez ensuite setfacl-md :pour s'occuper de tous les nouveaux éléments qui seront également créés.

Pour définir l'ACL par défaut, il vous suffit d'ajouter l'option d après choix -m (l'ordre compte!). Alors utilisez setfacl -md:g:sales:rx /datasi vous voulez que les ventes de groupe lisent et exécutent tout ce qui est créé dans le répertoire /data.

Lorsque vous utilisez des ACL par défaut, il peut également être utile de définir des ACL pour d'autres. Cela n'a généralement pas beaucoup de sens car vous pouvez également modifier les autorisations des autres en utilisant chmod. Cependant, ce que vous ne pouvez pas faire avec chmod, consiste à spécifier les droits qui doivent être accordés aux autres utilisateurs pour chaque nouveau fichier créé. Si vous voulez empêcher les autres d'obtenir des autorisations sur tout ce qui est créé dans / data, par exemple, utilisez setfacl -md:o::- /data.

Les ACL et les autorisations normales ne sont pas toujours bien intégrées. Des problèmes peuvent survenir si vous appliquez une ACL par défaut à un répertoire, puis des éléments sont ajoutés à ce répertoire, puis essayez de modifier les autorisations normales. Les modifications qui s'appliquent aux autorisations normales ne seront pas bien reflétées dans la vue d'ensemble de l'ACL. Pour éviter les problèmes, définissez d'abord les autorisations normales, puis définissez les ACL par défaut (et essayez de ne plus les modifier par la suite).

Exemple de gestion des droits élevés à l'aide d'ACL

Dans cet exemple, vous continuerez avec les répertoires /data/account et /data/sales que vous avez créés précédemment. Dans les exemples précédents, vous vous êtes assuré que le groupe de ventes dispose d'autorisations sur /data/sales et que le groupe de comptes dispose d'autorisations sur /data/account.

Tout d'abord, assurez-vous que le groupe de comptes obtient des autorisations de lecture sur le répertoire /data/sales et que le groupe de ventes obtient des autorisations de lecture sur le répertoire /data/account.

Vous définissez ensuite les ACL par défaut pour vous assurer que tous les nouveaux fichiers disposent des autorisations correctes définies pour tous les nouveaux éléments.

  1. Ouvrez un terminal.
  2. Exécuter setfacl -mg:account:rx /data/sales и setfacl -mg:sales:rx /données/compte.
  3. Exécuter getfaclpour vous assurer que les autorisations ont été définies comme vous le souhaitez.
  4. Exécuter setfacl -md:g:account:rwx,g:sales:rx /data/salespour définir l'ACL par défaut pour le répertoire des ventes.
  5. Ajoutez une ACL par défaut pour le répertoire /data/account en utilisant setfacl -md:g:sales:rwx,g:account:rx /data/account.
  6. Vérifiez que les paramètres ACL sont en vigueur en ajoutant un nouveau fichier à /data/sales. Complet toucher /données/ventes/nouveaufichier et exécuter getfacl /data/sales/nouveaufichier pour vérifier les autorisations actuelles.

Définition des autorisations par défaut avec umask

Ci-dessus, vous avez appris à utiliser les ACL par défaut. Si vous n'utilisez pas d'ACL, il existe une option shell qui détermine les autorisations par défaut que vous obtiendrez : umask (masque inversé). Dans cette section, vous apprendrez à modifier les autorisations par défaut avec umask.

Vous avez peut-être remarqué que lorsque vous créez un nouveau fichier, certaines autorisations par défaut sont définies. Ces autorisations sont déterminées par le paramètre umask. Ce paramètre de shell s'applique à tous les utilisateurs lors de la connexion. En paramètre umask une valeur numérique est utilisée, qui est soustraite des autorisations maximales pouvant être définies automatiquement pour le fichier ; le paramètre maximum pour les fichiers est 666 et pour les répertoires est 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.

Parmi les nombres utilisés dans umask, comme dans le cas des arguments numériques de la commande chmod, le premier chiffre fait référence aux autorisations de l'utilisateur, le deuxième aux autorisations du groupe et le dernier aux autorisations par défaut définies pour les autres. Signification umask le 022 par défaut donne 644 pour tous les nouveaux fichiers et 755 pour tous les nouveaux répertoires créés sur votre serveur.

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

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

Un moyen simple de voir comment fonctionne le paramètre umask est le suivant : commencez avec les autorisations par défaut du fichier définies sur 666 et soustrayez umask pour obtenir les autorisations effectives. Faites de même pour le répertoire et ses autorisations par défaut de 777.

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

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

Les paramètres appliqués dans ce fichier s'appliquent uniquement à l'utilisateur individuel ; c'est donc une bonne méthode si vous avez besoin de plus de détails. Personnellement, j'aime cette fonctionnalité pour changer l'umask par défaut pour l'utilisateur root en 027 tandis que les utilisateurs normaux exécutent avec l'umask par défaut de 022.

Travailler avec des attributs utilisateur étendus

Ceci est la dernière section sur les autorisations Linux.

Lorsque vous travaillez avec des autorisations, il existe toujours une relation entre un objet utilisateur ou groupe et les autorisations dont disposent les objets utilisateur ou groupe sur un fichier ou un répertoire. Une méthode alternative pour protéger les fichiers sur un serveur Linux consiste à travailler avec des attributs.
Les attributs font leur travail quel que soit l'utilisateur qui accède au fichier.

Comme pour les ACL, les attributs de fichier peuvent devoir inclure l'option monter.

Ceci est une option utilisateur_xattr. Si vous obtenez un message "opération non prise en charge" lorsque vous travaillez avec des attributs utilisateur étendus, assurez-vous de définir le paramètre monter dans /etc/fstab.

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

Vous trouverez ci-dessous les attributs les plus utiles que vous pouvez appliquer :

A Cet attribut garantit que l'heure d'accès au fichier du fichier ne change pas.
Généralement, chaque fois qu'un fichier est ouvert, le temps d'accès du fichier doit être enregistré dans les métadonnées du fichier. Cela a un impact négatif sur les performances ; donc pour les fichiers qui sont consultés régulièrement, l'attribut A peut être utilisé pour désactiver cette fonction.

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

c Si vous utilisez un système de fichiers prenant en charge la compression au niveau du volume, cet attribut de fichier garantit que le fichier est compressé la première fois que le mécanisme de compression est activé.

D Cet attribut garantit que les modifications apportées aux fichiers sont écrites sur le disque immédiatement plutôt que d'abord mises en cache. Il s'agit d'un attribut utile sur les fichiers de base de données importants pour s'assurer qu'ils ne se perdent pas entre le cache de fichiers et le disque dur.

d Cet attribut garantit que le fichier ne sera pas enregistré dans les sauvegardes où l'utilitaire de vidage est utilisé.

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

i Cet attribut rend le fichier immuable. Par conséquent, aucune modification ne peut être apportée au fichier, ce qui est utile pour les fichiers nécessitant une protection supplémentaire.

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

s Remplacez les blocs dans lesquels le fichier a été enregistré à 0 après la suppression du fichier. Cela garantit qu'un fichier ne peut pas être restauré une fois qu'il a été supprimé.

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

Si vous souhaitez appliquer les attributs, vous pouvez utiliser la commande chattr. Par exemple, utilisez chattr +s unfichierpour appliquer des attributs à un fichier. Besoin de supprimer un attribut ? Utilisez ensuite chattr -s unfichieret 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 à utiliser les autorisations. Vous avez lu les trois autorisations de base, les autorisations avancées et comment appliquer les ACL sur un système de fichiers. Vous avez également appris à utiliser l'option umask pour appliquer les autorisations par défaut. À la fin de cet article, vous avez appris à utiliser les attributs étendus par l'utilisateur pour appliquer une couche supplémentaire de sécurité du système de fichiers.

Si vous avez aimé cette traduction, veuillez l'écrire dans les commentaires. Il y aura plus de motivation pour faire des traductions utiles.

Correction de quelques fautes de frappe et de grammaire dans l'article. Réduction de certains paragraphes volumineux en plus petits pour une meilleure lisibilité.

Au lieu de "Seule une personne disposant de droits d'administration sur le répertoire peut appliquer l'autorisation d'exécution." fixé à "Seule une personne disposant d'autorisations d'écriture sur le répertoire peut appliquer l'autorisation d'exécution.", ce qui serait plus correct.

Merci pour les commentaires berez.

Remplacé :
Si vous n'êtes pas le propriétaire de l'utilisateur, le shell vérifiera si vous êtes membre d'un groupe, également appelé groupe du fichier.

Pour:
Si vous n'êtes pas le propriétaire du fichier, le shell vérifiera si vous êtes membre d'un groupe disposant d'autorisations sur le fichier. Si vous êtes membre de ce groupe, vous accéderez au fichier avec les autorisations définies par le groupe et le shell arrêtera la vérification.

Merci pour votre commentaire CryptoPirate

Source: habr.com

Ajouter un commentaire