L'un des défis de l'administration de Linux dans l'environnement commercial moderne est l'attente selon laquelle nous pouvons et devons gérer qui a accès à quelles informations. Il était une fois, les seules personnes qui avaient besoin d'accéder aux systèmes de fichiers Linux pouvaient être classées de manière générale :via les autorisations du système de fichiers Linux.
Réviser les bases
Le système de fichiers Linux nous donne trois types d'autorisations. Voici une revue simplifiée :
- U ser (ou utilisateur propriétaire)
- G groupe (ou groupe propriétaire)
- O là (tous les autres)
Avec ces autorisations, nous pouvons accorder trois types d'accès (en fait cinq, mais nous y reviendrons dans une minute) :
- R lire
- W rite
- eX exécuter
Ces niveaux d'accès sont souvent adéquats dans de nombreux cas. Supposons que vous disposiez d'un répertoire contenant les fichiers du service de comptabilité. Vous pouvez définir ces autorisations sur :
drwxrwxr-x 2 accounting accounting 12 Jan 8 15:13
L'utilisateur du service comptable (le propriétaire de l'utilisateur) peut lire et écrire dans l'annuaire, et les membres du service accounting groupe (ou groupe propriétaire) peut lire et écrire. D'autres (utilisateurs n'appartenant pas au service de comptabilité) peuvent cependant voir et exécuter ce qui s'y trouve, ce que certains pourraient penser que c'est une mauvaise idée.
[ Également populaire : Linux sysadmin basics :User account management ]
Donc, nous pourrions changer les permissions en ceci :
drwxrwx--- 2 accounting accounting 12 Jan 8 15:13 .
Remarque : Vous pouvez également utiliser des autorisations spéciales pour contrôler des paramètres tels que le propriétaire réel des nouveaux fichiers créés dans ce répertoire, ainsi que le bit collant qui contrôle si les membres du groupe peuvent supprimer les fichiers des autres. Cependant, cela sort du cadre de cette discussion.
Affichage de l'ACL actuelle
Et si vous avez un stagiaire en comptabilité (Kenny) qui doit être capable de lire certains fichiers (ou même uniquement les fichiers appartenant à Fred, son manager) ? Ou peut-être que les personnes du service commercial ont également besoin d'accéder à la accounting fichiers du propriétaire pour créer des factures pour l'équipe de Fred afin de facturer les clients, mais vous ne voulez pas que l'équipe de vente voie les autres rapports générés par l'équipe de Fred. Cette situation peut être délicate car, avec des autorisations régulières, chaque fichier et répertoire ne peut avoir qu'un seul propriétaire d'utilisateur et de groupe à la fois. Ce type de situation est ce que les listes de contrôle d'accès (ACL) Linux étaient censées résoudre.
Les ACL nous permettent d'appliquer un ensemble plus spécifique d'autorisations à un fichier ou à un répertoire sans (nécessairement) modifier la propriété et les autorisations de base. Ils nous permettent d'"ajouter" l'accès à d'autres utilisateurs ou groupes.
Nous pouvons voir l'ACL actuel en utilisant le getfacl commande :
[root]# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
Nous pouvons voir qu'en ce moment, il n'y a pas d'ACL sur ce répertoire car les seules autorisations répertoriées sont pour l'utilisateur, le groupe et autre. Dans ce cas, c'est normal, car je viens de créer ce répertoire dans le laboratoire et je n'ai rien fait d'autre que d'attribuer la propriété. Commençons donc par ajouter une ACL par défaut :
Définir une ACL
La syntaxe pour définir une ACL ressemble à ceci :
setfacl [option] [action/specification] file
L''action' serait -m (modifier) ou -x (supprimer), et la spécification serait l'utilisateur ou le groupe suivi des autorisations que nous voulons définir. Dans ce cas, nous utiliserions l'option -d (par défaut). Ainsi, pour définir l'ACL par défaut pour ce répertoire, nous exécuterions :
[root]# setfacl -d -m accounting:rwx /accounting
Après quoi, nous pouvons maintenant voir les informations ACL par défaut pour ce répertoire :
[root]# getfacl /accounting
[root]# getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
default:user::rwx
default:user:accounting:rwx
default:group::rwx
default:mask::rwx
default:other::---
Et si Fred crée un fichier dans ce répertoire ?
[fred]$ touch test
[fred]$ ls -la
drwxrwx---+ 2 accounting accounting 18 Jan 8 17:51 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
-rw-rw----+ 1 fred accounting 0 Jan 8 17:51 test
[fred]$ getfacl test
# file: test
# owner: fred
# group: accounting
user::rw-
user:accounting:rwx #effective:rw-
group::rwx #effective:rw-
Que se passe-t-il si Kenny essaie de créer un fichier ? Vous pouvez le deviner car kenny n'est pas dans la accounting groupe, il n'aura pas la permission. Mais nous voulons que Kenny ait une bonne expérience de travail avec nous, nous devons donc lui donner la possibilité de voir quels fichiers se trouvent dans la accounting répertoire, et nous voulons qu'il puisse créer de nouveaux fichiers :
[root@lab1 accounting]setfacl -m kenny:rwx /accounting
[root]getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx
Jusqu'ici tout va bien. Mais que se passe-t-il si nous ne voulons pas que cet utilisateur crée des fichiers dans la accounting annuaire? Au lieu de cela, nous voulons seulement le laisser lire les fichiers là-bas, et il peut créer de nouveaux fichiers dans son propre dossier.
[ Article connexe : Principes de base de l'administrateur système Linux :gestion des comptes utilisateur avec les UID et les GID ]
Nous pouvons définir l'accès de Kenny sur la accounting dossier comme celui-ci :
[root@lab1 accounting]# setfacl -m kenny:r-x /accounting
[root]# getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
User:kenny:r-x
Maintenant, nous faisons de Kenny son propre dossier, lui donnons la propriété, puis faisons la accounting regrouper le propriétaire du groupe afin que d'autres personnes de la accounting groupe peut voir ce qu'il y a dedans :
[root@lab1 accounting]# mkdir ./kenny
[root]# chown kenny:accounting ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:rwx
group::rwx
Vous avez créé un dossier dans la accounting groupe appartenant à l'utilisateur kenny . Il peut maintenant voir le dossier comptable, mais ne crée que des fichiers dans son propre dossier :
[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test
Notez que parce que le dossier appartient à la accounting groupe, n'importe qui dans ce groupe peut y placer des fichiers. Parce que nous avons affaire à un stagiaire, ce facteur est probablement correct. Cependant, que se passe-t-il si nous donnons à Kenny une promotion au poste d'auditeur en chef et que nous voulons garder son travail secret pour Fred ?
[root]# setfacl -m fred:- ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
Et si nous ne voulions personne pour voir sur quoi travaille Kenny ?
[root]# setfacl -m g:accounting:- ./kenny
Remarque : Lorsque nous voulons définir un groupe ACL, nous devons le spécifier en mettant g: devant le nom du groupe. Pour les utilisateurs, changez simplement le g à un u , mais setfacl supposera que nous parlons d'un utilisateur si vous ne mettez rien à cet endroit.
Nous devons encore supprimer les autorisations de base du propriétaire du groupe afin que le reste de l'équipe comptable ne puisse pas fouiner dans les rapports de Kenny :
[root]# chmod g-rwx ./kenny
[root]# ls -al
total 0
drwxrwx-wx+ 3 accounting accounting 44 Jan 9 16:38 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
drwx------+ 2 kenny accounting 18 Jan 9 17:07 kenny
-rw-rw----+ 1 root root 0 Jan 9 16:33 test
-rw-rw----+ 1 kenny accounting 0 Jan 9 16:27 test2
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
group::rwx #effective:---
[root]# su jan
[jan]$ touch ./kenny/test
touch: cannot touch ‘./kenny/test’: Permission denied
Maintenant, nous pouvons gérer qui d'autre peut voir ou écrire dans le dossier de Kenny sans changer la propriété. Donnons au PDG (Lisa, qui n'est pas membre de l'équipe comptable et n'aura pas accès au reste du dossier) accès aux affaires de Kenny :
[root@lab1 accounting]# useradd lisa
[root]# setfacl -m u:lisa:rwx ./kenny
[root]# su lisa
[lisa]$ touch ./kenny/lisa
[lisa]$ ls ./kenny
lisa test
[lisa]$ touch test
touch: cannot touch ‘test’: Permission denied
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
user:lisa:rwx
group::rwx
group:accounting:---
Notez à nouveau que les autorisations du propriétaire du groupe restent largement ouvertes, mais le groupe de comptabilité (qui est toujours le propriétaire) n'a plus accès à ce dossier. Alors, à qui appartient-il ?
drwxrwx---+ 2 kenny accounting 30 Jan 9 17:16 kenny
Cette partie est délicate. Il est utile de savoir que nous pouvons supprimer les autorisations du propriétaire sans modifier le propriétaire, mais vous voudrez peut-être vous demander si c'est le résultat que vous souhaitez.
Conclusion
Ce sont donc les bases. Les ACL peuvent prêter à confusion, je vous encourage donc à donner les pages de manuel pour setfacl et getfacl une bonne lecture. Il y a beaucoup plus de choses intéressantes et utiles que vous pouvez faire avec ces outils, mais j'espère que vous en comprenez maintenant assez pour vous lancer.
[ Voulez-vous essayer Red Hat Enterprise Linux ? Télécharge le maintenant gratuitement. ]