Linux-Berechtigungen für ein Remote-Mount

1

Wenn ich unter Windows die Berechtigungen für einen Remote-Ordner betrachte, werden die Konten mit dem Computernamen oder der Domäne qualifiziert, dh mit der Berechtigung für den Kontonamen.

Wenn ich unter Linux eine VM mit einem Mount auf einem Remote-Laufwerk besitze und der Eigentümer eines Ordners auf dem Mount "root" ist, ist das dann mein Root oder der Root des Remote-Systems?

Unter Linux scheint alles viel zu einfach, um zu funktionieren, sobald ein Netzwerk involviert ist. Mir fehlt eindeutig etwas.

Luke

linux permissions Luke Puplett
quelle

Antworten:

1

Dies ist leider eines der verwirrendsten Dinge bei der Dateifreigabe unter Unixes. Und ich bin schlecht darin, verwirrende Dinge zu erklären.

Was Sie sehen in ls -lAusgabe (zum Beispiel), ist der Fernbedienungs - ID des Benutzers aus der Sicht des lokalen Systems übersetzt.

Wenn Programme wie lsdie Standardfunktionen zum Nachschlagen von Dateiinformationen verwenden, kann der Dateisystemtreiber ihnen nur numerische Benutzer-IDs und keine Textnamen zuweisen. (Bislang nicht zu unterschiedlich von Windows.) Um die UIDs in Namen zu übersetzen, rufen Sie lseine völlig andere Betriebssystemkomponente auf, die Namensdienstbibliotheken, die keine Kenntnis darüber haben, woher diese UID stammt, und daher nur Konten übersetzen können, die die Betriebssystem weiß Bescheid, kann aber nicht zurückgehen und den Dateisystemtreiber um Hilfe bitten. (Hier kommt der Unterschied ins Spiel.)

Wenn der Server beispielsweise über zwei Dateien verfügt, von denen eine der Root-ID (UID 0) und die andere der Luke-ID (UID 1000) gehört, lswird nur bekannt sein, dass sie "0" und "1000" gehören für lokale Konten mit denselben UIDs. "0" ist immer root, aber "1000" kann Luke sein oder nicht. Wenn die UID zu einem in LDAP oder NIS oder AD gespeicherten Konto gehört und das Client-Betriebssystem tatsächlich so konfiguriert ist , dass in LDAP nach Benutzerkonten gesucht wird, wird der richtige Benutzername angegeben. Andernfalls könnte es tatsächlich lügen, da lokale Konto-UIDs (1000, 1001, ...) dazu neigen, unterschiedlichen Personen auf unterschiedlichen Computern zu entsprechen.

(Es gibt Möglichkeiten, wie der Dateisystemtreiber Programmen den vollständigen Benutzernamen in Form von "erweiterten Attributen" mitteilen kann. Leider gibt es trotz verschiedener Versuche keine Standardmethode, und Programme wie diese lsversuchen im Allgemeinen, dateisystemspezifische Tricks zu vermeiden . Noch mehr leider nicht alle Netzwerk - Dateisystem - Protokolle können die Benutzernamen übertragen. CIFS aka SMB kann, NFSv4 kann, die meisten anderen diejenigen nicht kann)

Aber nichts davon ist wirklich von Bedeutung, da das , was Sie mit der Datei tun können, immer davon abhängt, was der Server weiß und nicht davon, was der Client sieht. Wenn Sie zum Beispiel verwenden sshfs, meldet es sich über SSH mit Ihrem Benutzernamen (z. B. sshfs luke@fileserver) beim Server an und der Server lässt Sie nichts tun, was Sie nicht tun sollen. Dasselbe gilt für CIFS, AFS usw.

Grawity
quelle
Es könnte also ein völlig falscher Besitzer angezeigt werden, wenn die UID des realen Besitzers mit einer UID übereinstimmt, die ich vor Ort habe? Ernsthaft? Wie unterscheidet der Server zwei lokale Benutzerkonten mit derselben UID, ohne dass Daten für die ausstellende Behörde der UID gespeichert sind?
Luke Puplett
@ LukePuplett: Ja, würde es. Wenn der Server "Diese Datei gehört der UID 1000" meldet, zeigt der Client an, was der Client unter dieser UID kennt. Auch hier muss der Server nicht differenzieren. Bei CIFS, SSHFS oder AFS interessieren Client-UIDs den Server nicht , nur weil der Client lügen könnte . Der Server kümmert sich nur um sichere Anmeldeinformationen wie Passwort oder Kerberos-Ticket, die Sie vorlegen. (Dasselbe gilt für Windows. Für den Netzwerkdateizugriff unter Windows wird entweder Kerberos oder NTLM mit Ihrem Benutzernamen und Kennwort verwendet. Es werden keine SIDs mit oder ohne
Berechtigungspräfix verwendet
@ LukePuplett: Natürlich gibt es Ausnahmen. NFS hat keine "Passwort" -Authentifizierung. Wenn Sie Kerberos nicht ausführen können, ist auth-by-UID die einzige verbleibende Methode (der Client gibt an, dass "UID 1000 versucht, auf diese Datei zuzugreifen", und der Server geht davon aus). In dieser Situation kann es vorkommen, dass UIDs nicht übereinstimmen oder der Client UIDs fälschen kann. In diesem Fall ist die einzige Möglichkeit, NFS überhaupt nicht zu verwenden. Aber auch dies ist eine Ausnahme. Andere Protokolle (wie CIFS oder NFS mit Kerberos) kümmern sich überhaupt nicht um lokale UIDs.
Grawity
@LukePuplett: Denken Sie auch daran, dass die "ausstellende Behörde" in vielen Fällen nicht vertrauenswürdig ist. Stellen Sie sich ein Windows-Image vor, das auf ein Dutzend Computer geklont und an verschiedene Kunden verkauft wurde. Jetzt haben Sie alle unterschiedliche Konten mit derselben SID, einschließlich des Berechtigungsteils. Und hier sagt Microsoft, dass es keine Rolle spielt. Daher spielt auch die fehlende Berechtigung in Unix-UIDs keine Rolle.
Grawity
Danke für die Information. FWIW Windows verwendet nur SIDs, der Benutzername und das Passwort beweisen lediglich den autorisierten Kontoinhaber bei der Anmeldung. Der Benutzername wird nicht in ACEs gespeichert (siehe technet.microsoft.com/en-us/library/cc961995.aspx). Nehmen Sie zwei geklonte Windows-PCs mit derselben Computer-SID. Geben Sie auf PC1 Administratorrechten für eine Datei auf USB, und legen Sie sie auf PC2 ab. Der Administrator erhält dann Zugriff, da die SID identisch ist. Ich verstehe Linux / Unix überhaupt nicht, aber das Fehlen eines Berechtigungselements sieht nach einem seltsamen Design aus.
Luke Puplett
0

Der Eigentümer ist der Root-Benutzer auf dem Remotecomputer. Wenn Sie auf dem Remotecomputer als Root darauf zugreifen möchten, müssen Sie ihn als Root auf dem Remotecomputer bereitstellen.

Mit anderen Worten, dies sollte funktionieren (lokaler Benutzer aye, Remote-Benutzer root):

aye@ayes-machine$ sshfs root@bees-machine:/path /local-path

Dies funktioniert nicht (lokaler Benutzer root, entfernter Benutzer bee):

aye@ayes-machine$ sudo sshfs bee@bees-machine:/path /local-path
l0b0
quelle