Zu den Herausforderungen bei der Verwaltung von Linux in der modernen Geschäftsumgebung gehört die Erwartung, dass wir verwalten können und sollten, wer Zugriff auf welche Informationen hat. Früher konnten die einzigen Leute, die Zugriff auf Linux-Dateisysteme benötigten, allgemein kategorisiert werden:durch Linux-Dateisystemberechtigungen.
Wiederholung der Grundlagen
Das Linux-Dateisystem gibt uns drei Arten von Berechtigungen. Hier ist eine vereinfachte Überprüfung:
- Du ser (oder Benutzereigentümer)
- G roup (oder Besitzergruppe)
- O ther (alle anderen)
Mit diesen Berechtigungen können wir drei (eigentlich fünf, aber dazu kommen wir gleich) Zugriffsarten gewähren:
- R lesen
- W Ritus
- eX ecute
Diese Zugriffsebenen sind in vielen Fällen oft ausreichend. Angenommen, Sie haben ein Verzeichnis, in dem sich Dateien aus der Buchhaltung befinden. Sie können diese Berechtigungen folgendermaßen festlegen:
drwxrwxr-x 2 accounting accounting 12 Jan 8 15:13
Der Buchhaltungsdienstbenutzer (der Benutzereigentümer) kann im Verzeichnis lesen und schreiben, und Mitglieder der accounting Gruppe (oder Besitzergruppe) kann lesen und schreiben. Andere (Benutzer, die nicht in der Buchhaltungsabteilung sind) können jedoch sehen und ausführen, was darin enthalten ist, was einige für eine schlechte Idee halten könnten.
[Auch beliebt:Grundlagen des Linux-Systemadministrators:Benutzerkontenverwaltung ]
Wir könnten also die Berechtigungen wie folgt ändern:
drwxrwx--- 2 accounting accounting 12 Jan 8 15:13 .
Hinweis: Sie können auch spezielle Berechtigungen verwenden, um Einstellungen zu steuern, z. B. wem tatsächlich neue Dateien gehören, die in diesem Verzeichnis erstellt wurden, sowie das Sticky Bit die steuert, ob Mitglieder der Gruppe die Dateien der anderen löschen können. Dies ist jedoch außerhalb des Rahmens dieser Diskussion.
Anzeigen der aktuellen ACL
Was ist, wenn Sie einen Buchhaltungspraktikanten (Kenny) haben, der in der Lage sein muss, bestimmte Dateien zu lesen (oder sogar nur die Dateien, die Fred, seinem Manager, gehören)? Oder vielleicht brauchen die Leute in der Verkaufsabteilung auch Zugriff auf die accounting die Dateien des Eigentümers verwenden, um Rechnungen für Freds Team zu erstellen, um Kunden Rechnungen zu stellen, aber Sie möchten nicht, dass das Verkaufsteam die anderen Berichte sieht, die Freds Team generiert. Diese Situation kann schwierig sein, da jede Datei und jedes Verzeichnis mit regulären Berechtigungen jeweils nur einen Benutzer und Gruppenbesitzer haben kann. Diese Art von Situation ist das, was Linux Access Control Lists (ACLs) lösen sollten.
ACLs ermöglichen es uns, einen spezifischeren Satz von Berechtigungen auf eine Datei oder ein Verzeichnis anzuwenden, ohne (notwendigerweise) den Basisbesitz und die Berechtigungen zu ändern. Sie ermöglichen uns den Zugriff für andere Nutzer oder Gruppen.
Wir können die aktuelle ACL mit getfacl anzeigen Befehl:
[root]# getfacl /accounting
getfacl: Removing leading '/' from absolute path names
# file: accounting
# owner: accounting
# group: accounting
user::rwx
group::rwx
other::---
Wir können jetzt sehen, dass es in diesem Verzeichnis keine ACLs gibt, da die einzigen aufgelisteten Berechtigungen für den Benutzer, die Gruppe und andere gelten. In diesem Fall ist das zu erwarten, da ich dieses Verzeichnis gerade im Labor erstellt und nichts anderes getan habe, als die Eigentümerschaft zuzuweisen. Beginnen wir also mit dem Hinzufügen einer Standard-ACL:
Festlegen einer ACL
Die Syntax zum Setzen einer ACL sieht folgendermaßen aus:
setfacl [option] [action/specification] file
Die 'Aktion' wäre -m (ändern) oder -x (entfernen), und die Spezifikation wäre der Benutzer oder die Gruppe, gefolgt von den Berechtigungen, die wir festlegen möchten. In diesem Fall würden wir die Option -d verwenden (Standardwerte). Um also die Standard-ACL für dieses Verzeichnis festzulegen, würden wir Folgendes ausführen:
[root]# setfacl -d -m accounting:rwx /accounting
Danach können wir jetzt die Standard-ACL-Informationen für dieses Verzeichnis sehen:
[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::---
Was passiert, wenn Fred eine Datei in diesem Verzeichnis erstellt?
[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-
Was passiert, wenn Kenny versucht, eine Datei zu erstellen? Sie können das vielleicht erraten, weil kenny ist nicht in der accounting Gruppe hat er keine Berechtigung. Aber wir möchten, dass Kenny eine gute Erfahrung bei der Zusammenarbeit mit uns macht, also müssen wir ihm die Möglichkeit geben, zu sehen, welche Dateien sich in der accounting befinden Verzeichnis, und wir möchten, dass er neue Dateien erstellen kann:
[root@lab1 accounting]setfacl -m kenny:rwx /accounting
[root]getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx
So weit, ist es gut. Aber was ist, wenn wir nicht möchten, dass dieser Benutzer Dateien in der accounting erstellt? Verzeichnis? Stattdessen wollen wir ihn nur die Dateien dort lesen lassen, und er kann neue Dateien in seinem eigenen Ordner erstellen.
[Verwandter Artikel: Linux-Systemadministratorgrundlagen:Benutzerkontenverwaltung mit UIDs und GIDs]
Wir können Kennys Zugriff auf die accounting festlegen Ordner wie folgt:
[root@lab1 accounting]# setfacl -m kenny:r-x /accounting
[root]# getfacl ./
# file: .
# owner: accounting
# group: accounting
user::rwx
User:kenny:r-x
Jetzt machen wir Kenny zu seinem eigenen Ordner, übertragen ihm die Eigentümerschaft und führen dann die accounting durch Gruppieren Sie den Gruppenbesitzer damit andere Personen in der accounting Gruppe kann sehen, was darin enthalten ist:
[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
Sie haben einen Ordner innerhalb der accounting erstellt Gruppe, die dem Benutzer kenny gehört . Er kann jetzt den Buchhaltungsordner sehen, aber nur Dateien in seinem eigenen Ordner erstellen:
[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test
Beachten Sie, dass der Ordner der accounting gehört Gruppe kann jeder in dieser Gruppe Dateien dort ablegen. Da wir es mit einem Praktikanten zu tun haben, ist dieser Faktor wahrscheinlich in Ordnung. Was aber, wenn wir Kenny zum Chefrevisor befördern und seine Arbeit vor Fred geheim halten wollen?
[root]# setfacl -m fred:- ./kenny
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
Was wäre, wenn wir niemanden wollten um zu sehen, woran Kenny arbeitet?
[root]# setfacl -m g:accounting:- ./kenny
Hinweis: Wenn wir eine Gruppe einrichten möchten ACL, wir müssen dies spezifizieren, indem wir g: einfügen vor dem Namen der Gruppe. Für Benutzer ändern Sie einfach den g zu einem u , aber setfacl gehen davon aus, dass es sich um einen Benutzer handelt, wenn Sie an dieser Stelle nichts eingeben.
Wir müssen noch die Basisberechtigungen für den Gruppenbesitzer entfernen, damit der Rest des Buchhaltungsteams nicht in Kennys Berichte hineinschnüffeln kann:
[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
Jetzt können wir verwalten, wer sonst Kennys Ordner sehen oder in ihn schreiben kann, ohne den Eigentümer zu ändern. Geben wir dem CEO (Lisa, die kein Mitglied des Buchhaltungsteams ist und keinen Zugriff auf den Rest des Ordners hat) Zugriff auf Kennys Daten:
[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:---
Beachten Sie erneut, dass die Berechtigungen des Gruppeneigentümers weit offen bleiben, aber die Buchhaltungsgruppe (die immer noch der Eigentümer ist) keinen Zugriff mehr auf diesen Ordner hat. Also, wem gehört es?
drwxrwx---+ 2 kenny accounting 30 Jan 9 17:16 kenny
Dieser Teil ist schwierig. Es ist hilfreich zu wissen, dass wir die Berechtigungen des Eigentümers entziehen können, ohne den Eigentümer zu ändern, aber Sie sollten überlegen, ob dies das gewünschte Ergebnis ist.
Fazit
Das sind also die Grundlagen. ACLs können verwirrend sein, daher ermutige ich Sie, die Manpages für setfacl anzugeben und getfacl eine gute Lektüre. Es gibt viele weitere interessante und nützliche Dinge, die Sie mit diesen Tools tun können, aber hoffentlich verstehen Sie jetzt genug, um loszulegen.
[ Möchten Sie Red Hat Enterprise Linux ausprobieren? Laden Sie es jetzt kostenlos herunter. ]