Einführung
Der Analyst des Einzelhändlers muss einen Produktdatensatz lesen können, darf ihn aber nicht verändern. Die Datei ist vorhanden und ihre Blöcke sind gesund, trotzdem kann ein anderer Benutzer Permission denied erhalten. Speicherzustand und Autorisierung beantworten unterschiedliche Fragen: Sind die Daten verfügbar, und darf diese Identität darauf zugreifen?
HDFS verwendet einen Eigentümer, eine Gruppe und Berechtigungsbits für grundlegende Zugriffsentscheidungen. Sie arbeiten als normaler Eigentümer labex und geben einen Datensatz über die Gruppe bigdata für die vorbereitete Identität analyst frei. Eine weitere normale Identität, nobody, steht für eine Person außerhalb dieser Gruppe. Der NameNode läuft als hdfs; Sie sind nicht der HDFS-Superuser.
Sie lesen die vorhandenen Berechtigungen, richten einen reinen Lesezugriff für die Gruppe ein und reproduzieren ein Problem beim Durchqueren eines Verzeichnisses. Diese Prüfungen verwenden HDFS-Berechtigungen, keine lokalen Linux-Dateiberechtigungen. Die Umgebung dient zum Lernen mit einfacher Authentifizierung; sie demonstriert keine sichere Produktionsauthentifizierung wie Kerberos. Alle Beispieldaten sind unabhängig von vorherigen Labs. Verwenden Sie das Terminal.
Lesen Sie die Zugriffsregeln
In diesem Schritt ermitteln Sie Eigentümer, Gruppe und Zugriffsmodi eines privaten Datensatzes.
Beginnen Sie im lokalen Projektverzeichnis:
cd /home/labex/project
Die HDFS-Option -ls -d listet den Verzeichniseintrag selbst statt seines Inhalts auf. Prüfen Sie Verzeichnis und Datei gemeinsam:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Die wichtigen Felder sollten diese Modi und Identitäten enthalten; Größen und Zeitstempel variieren:
drwx------ ... labex labex ... /user/labex/basic-permissions/team
-rw------- ... labex labex ... /user/labex/basic-permissions/team/products.txt
Das erste Zeichen beschreibt das Objekt (d für ein Verzeichnis, - für eine Datei). Die nächsten neun Zeichen bilden drei Dreiergruppen: Eigentümer, Gruppe und andere Benutzer. r bedeutet Lesen, w Schreiben und x Ausführen beziehungsweise bei Verzeichnissen Durchqueren. Ein Bindestrich bedeutet, dass die entsprechende Berechtigung fehlt.
Bei einer Datei erlaubt Lesen den Zugriff auf den Inhalt und Schreiben dessen Änderung. Bei einem Verzeichnis erlaubt Lesen das Auflisten von Namen; Schreiben steuert zusammen mit dem Durchquerungsrecht das Erstellen oder Entfernen von Einträgen, und Ausführen erlaubt das Durchqueren des Verzeichnisses zum Zugriff auf ein benanntes untergeordnetes Objekt. Zum Lesen einer Datei benötigen Sie daher sowohl Berechtigungen entlang des Pfads als auch für die Datei selbst.
Der aktuelle Verzeichnismodus gibt labex vollständigen Zugriff und allen anderen keinen Zugriff. Die Datei erlaubt labex Lesen und Schreiben. Bestätigen Sie, dass der Eigentümer sie lesen kann:
hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Erwarteter Text:
notebook pen
folder notebook
Speichern Sie die anfängliche Auflistung mit lokaler Ausgabeumleitung:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/initial-permissions.txt
Sie haben eine private Datei erkannt, keine fehlende oder beschädigte Datei. Als Nächstes gewähren Sie der vorgesehenen Gruppe genau den Zugriff, den sie benötigt.
Geben Sie Daten für eine Gruppe nur lesend frei
In diesem Schritt erlauben Sie der Gruppe bigdata, das Verzeichnis zu durchqueren und die Datei zu lesen. Anschließend testen Sie den Zugriff des Analysten.
Die vorbereiteten Benutzer labex und analyst sind beide Mitglieder von bigdata. HDFS -chgrp ändert die Gruppe eines Objekts. Als Eigentümer und Mitglied der neuen Gruppe können Sie sie festlegen, ohne HDFS-Superuser zu werden:
hdfs dfs -chgrp bigdata /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt
Legen Sie die Modi mit -chmod fest. Jede Ziffer fasst eine Berechtigungsgruppe zusammen: r=4, w=2 und x=1. Addieren Sie die benötigten Werte für Eigentümer, Gruppe und andere:
| Modus | Eigentümer | Gruppe | Andere |
|---|---|---|---|
750 für ein Verzeichnis |
lesen, schreiben, durchqueren | lesen und durchqueren | kein Zugriff |
640 für eine Datei |
lesen und schreiben | lesen | kein Zugriff |
Setzen Sie den Verzeichnismodus:
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Setzen Sie den Dateimodus:
hdfs dfs -chmod 640 /user/labex/basic-permissions/team/products.txt
Testen Sie nun mit der tatsächlichen Analystenidentität. sudo -u analyst führt nur diesen Befehl als vorbereiteter normaler Benutzer aus; der absolute Pfad des HDFS-Clients wählt dasselbe Werkzeug. Dies ist ein Test einer anderen Identität und keine Aufforderung, normale Dateioperationen als Administrator auszuführen:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Dieselben beiden Produktzeilen sollten erscheinen. Die Gruppe kann das Verzeichnis durchqueren und die Datei lesen.
Testen Sie auch das Schreiben. -appendToFile würde den Inhalt einer lokalen Datei an eine HDFS-Datei anhängen, wenn der Zugriff dies zuließe. Die bereitgestellte schreibgeschützte Testdatei in /tmp enthält eine zusätzliche Bezeichnung, die nicht Teil des verlässlichen Datensatzes werden darf. Sie liegt außerhalb des privaten lokalen Heimatverzeichnisses, damit die normale Testidentität sie lesen kann. So wird gezielt die HDFS-Schreibberechtigung geprüft. Der nächste Befehl soll fehlschlagen.
sudo -u analyst /usr/local/bin/hdfs dfs -appendToFile /tmp/labex-hdfs-write-probe.txt /user/labex/basic-permissions/team/products.txt
Achten Sie auf Permission denied und einen Hinweis auf den Schreibzugriff. Dieser Fehler ist das gewünschte Ergebnis: Der Analyst kann lesen, aber nichts anhängen. Ein Rückgabestatus ungleich null ist bei dieser absichtlichen Zugriffsverweigerung normal; fahren Sie mit dem nächsten Schritt fort. Würde die Datei für alle beschreibbar gemacht, ginge dieser Schutz verloren.
Untersuchen Sie ein Problem beim Durchqueren eines Verzeichnisses
In diesem Schritt ändern Sie ein Berechtigungsbit, beobachten den entstehenden Zugriffsfehler und stellen nur den erforderlichen Zugriff wieder her.
Die Datei erlaubt der Gruppe derzeit das Lesen. Sagen Sie voraus, was passiert, wenn das Verzeichnis Gruppenmitgliedern das Auflisten von Namen, aber nicht mehr das Durchqueren erlaubt. 740 erhält den Eigentümerzugriff und das Gruppenleserecht, entfernt aber das Gruppenrecht x:
hdfs dfs -chmod 740 /user/labex/basic-permissions/team
Lesen Sie dieselbe Datei als derselbe Analyst. Der nächste Befehl soll fehlschlagen.
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Die Meldung zur Zugriffsverweigerung sollte auf das fehlende Durchquerungsrecht für das Verzeichnis hinweisen. Zusätzliche Leserechte an der Datei lösen dieses Problem nicht: Zuerst muss der Pfad durchquerbar sein. Stellen Sie das Gruppenbit x des Verzeichnisses wieder her, indem Sie zum geübten Modus zurückkehren:
hdfs dfs -chmod 750 /user/labex/basic-permissions/team
Bestätigen Sie, dass der Analyst wieder lesen kann:
sudo -u analyst /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Die ursprünglichen beiden Zeilen sollten wieder erscheinen. Testen Sie abschließend eine normale Identität außerhalb der Freigabegruppe. nobody dient nur als unbeteiligte Identität dieses Labs. Der nächste Befehl soll fehlschlagen.
sudo -u nobody /usr/local/bin/hdfs dfs -cat /user/labex/basic-permissions/team/products.txt
Die Verweigerung bestätigt, dass die Gruppenfreigabe den Datensatz nicht öffentlich gemacht hat. Speichern Sie die abschließende Auflistung:
hdfs dfs -ls -d /user/labex/basic-permissions/team /user/labex/basic-permissions/team/products.txt > /home/labex/project/output/final-permissions.txt
Lesen Sie das Ergebnis:
cat /home/labex/project/output/final-permissions.txt
Das Verzeichnis sollte drwxr-x--- und die Datei -rw-r----- zeigen, mit Eigentümer labex und Gruppe bigdata. Vergleichen Sie deren Bedeutung mit den anfänglichen privaten Modi. Sie haben einer bestimmten Gruppe den minimal erforderlichen Zugriff gewährt, statt Berechtigungsprüfungen abzuschalten oder 777 zu verwenden.
Zusammenfassung
Sie haben HDFS-Modi für Eigentümer, Gruppe und andere gelesen, eine Freigabegruppe zugewiesen und unterschiedliche Modi für Verzeichnis und Datei verwendet. Prüfungen mit echten Identitäten bestätigten, dass der Analyst lesen, aber nicht schreiben konnte, während ein unbeteiligter Benutzer nicht lesen konnte.
Durch das Entfernen und Wiederherstellen des Durchquerungsrechts haben Sie gelernt, warum eine lesbare Datei über ihren Pfad dennoch unerreichbar sein kann. In der nächsten Challenge finden und beheben Sie ein ähnliches Freigabeproblem eigenständig.
