staging.inyokaproject.org

kB schrieb:

Ok, da läuft etwas wild! Ein unter Linux mit dem einen Treiber mit Standardmethode (ln -s) angelegter Symlink funktioniert nicht mit dem anderen Treiber. Gilt in beiden Richtungen.

Oha, damit hätten wir 3 Varianten im Köcher, Symlinks in Windows-, NTFS-3G- und NTFS3-Codierung.

Wird denn ein von NTFS3 angelegter relativer Symlink von Windows erkannt?

UlfZibis schrieb:

[…] Wird denn ein von NTFS3 angelegter relativer Symlink von Windows erkannt?

Ist für den Artikel nicht relevant und mag an anderer Stelle, nicht hier, diskutiert werden.

Für den Artikel reichen wegen des Verhaltens unter Linux zwei Warnungen:

• „Symlinks: Mache das nicht!“

• „Treiber mischen: Mache das nicht!“

@ UlfZibis:

Option permissions – Mappt Pseudo-Besitzer und bildet darauf Linux-Dateirechte ab.

Option acl - Mappt Pseudo-Besitzer und bildet darauf Posix-ACLs ab.

Diesen Formulierungen möchte ich ganz entschieden widersprechen! Pseudo-Besitzer gibt es höchstens bei uid und gid, und auch da ist der Ausdruck "Pseudo…" nicht geeinet.

• der Besitzer ist im Linux-System echt, d.h. "persistent" eingerichtet und ist nicht, wie bei uid und gid nach dem Aushängen wieder weg! Also kein "Pseudo-Besitzer"

• Jede SID, auf die gemappt wird, ist auch im Windows-Dateisystem ein "echter" Besitzer. Man muss nur bei einer der betreffenden Dateien Eigenschaften > Sicherheit aufrufen, dann sieht man das (ich habe extra dafür eine Bildschiem-Aufnahme in meine Cloud gestellt, siehe dort). Er hat zwar keinen Namen, deshalb wird dort statt dessen seine SID angegeben, aber man kann seine Rechte in Windows abfragen und auch verändern. Das gilt nachher auch wieder in Linux. Also ist er "persistent" und nicht "transient" und damit nichts von "Pseudo…"

Ich weiß nicht, ob es sich hier nur um eine unglückliche Formulierung oder nicht sogar um ein gründliches Missverständnis handelt.

Es ist IMO genau so, wie ich geschrieben habe, und die von Tuxera gewählte Formulierung default user mapping ist gut und trifft genau den Sachverhalt! Und wenn ’mal eine Formulierung gut ist, dann müssen wir nicht meinen, es unbedingt besser machen zu müssen, und dann mit viel schlechteren, missverständlichen Formulierungen alles durcheinander bringen! Wer sind wir eigentlich bzw. was bilden wir uns ein zu sein?

Wie du siehst, habe ich inzwischen noch einiges an meinen Formulierungen gefeilt. Aber grundsätzlich halte ich daran fest: Ich will die gute Bezeichnung "default user mapping" von Tuxera, die ich nicht selbst erfunden habe, beibehalten und mit ihr arbeiten. So heißt das eben. Und "Pseudo" ist da gar nichts! Und wenn jemand die von Tuxera gewählte Bezeichnung nicht versteht, dann muss das ja nicht unbedingt an Tuxera liegen.

@kB:

Ist für den Artikel nicht relevant und mag an anderer Stelle, nicht hier, diskutiert werden.

+1 ❗ ❗

Für den Artikel reichen wegen des Verhaltens unter Linux zwei Warnungen: … …

nochmal +1 !

Ok, da läuft etwas wild! Ein unter Linux mit dem einen Treiber mit Standardmethode (ln -s) angelegter Symlink funktioniert nicht mit dem anderen Treiber. Gilt in beiden Richtungen.

Warum das so ist, darauf muss der Artikel nicht eingehen.

völlig einverstanden! Wir schreiben keine Dissertation, sonden einen Wiki-Artikel!

Nochmal @UlfZibis

Ich will jetzt nochmal mit etwas mehr Gelassenheit antworten:

Natürlich bezieht sich das "default" bei default user mapping auf das User-Mapping. Das User-Mapping wird erst durch eine der beiden Optionen permissions oder acl ausgelöst. Sonst findet es eben nicht statt. Das macht seine Position im Artikel deutlich, kann aber nochmal explizit erwähnt werden.

default user mapping ist das User-Mapping wie es stattfindet, wenn keine weiteren Vorgaben dazu kommen. So wird "Default…" häufig gebraucht. Das ist wohl verständlich. Der Treiber wählt sich "per default" für das Mapping selbst geeignete SIDs.

Kommen nun durch eine UserMapping-Datei weitere Informationen dazu, nämlich welche SID der Treiber jeweils wählen soll, dann nimmt er eben diese SIDs und nicht seine Default-SIDs. Ist doch klar, oder?

Nun kommt noch folgendes hinzu (ein besonderer "Service" des Treibers): Wenn der Treiber eine UserMapping-Datei findet, dann wird dadurch auch dann ein User-Mapping ausgelöst, wenn keine der Optionen permissions oder acl vorliegt. Und weil er dann nicht weiß, welche der beiden Optionen er dafür wählen soll, nimmt er in diesem speziellen Fall eben acl. Das ist alles!

Der Begriff könnte aber auch mit dem Verfahren von NTFS3 als vergleichbar angesehen und verwechselt werden, wo das Mapping ja tatsächlich per default stattfindet. Also wie gesagt, wenn Du den unbedingt verwenden willst, dann definiere ihn bitte ganz genau im Artikel.

Das stimmt so nicht. Bei NTFS3 wird gar nichts gemappt. Das habe ich untersucht und auch mit einer Bildschirm-Kopie aus Windows aufgezeigt. Es gibt in Windows für die Linux-Benutzer keine SID, die Linux-Dateien sind in Windows völlig herrenlos. Bei NTFS3 findet also überhaupt kein User-Mapping statt, nicht default und nicht mit Vorgaben.

Und zweitens verwechselst du die Begriffe Default und out of the box. Default heißt immer "so wird vorgegangen, wenn keine weiteren Vorgaben dazukommen". Es gibt viele Beispiele, wo "Default" eben nicht mit "out of the box" gleichbedeutend ist. Nebenbei passt das auch sprachlich: "default" bedeutet "fehlend", d.h. wenn weitere Vorgaben fehlen. Und so ist es doch genau beim default user mapping.

Wir müssen nicht immer versuchen, alles besser zu machen – besonders dann, wenn das schon gut ist!

Jetzt zum Schluss noch eine Frage an den Experten kB:

UlfZubis hat Recht mit seiner Feststellung, dass

wmic useraccount get name,sid …

in Windows 10 nicht mehr läuft. vmic ist seit ca. einem Jahr "stillschweigend" deprecated und geht nicht mehr, auch nicht als Administrator. Zum Ermitteln des SID eines Benutzers wird nur noch ein recht kompliziertes Verfahren als Administrator in der PowerShell 7 aufgeführt. Ich bin überzeugt, dass es auch einfacher gehen muss, denn im Dateisystem sind die SID unter den Metadaten ja vorhanden.

Kennst Du ein einfaches Verfahren, um die SID zu ermitteln? Wenn man eine UserMap-Datei von Hand erstellen will, dann braucht man diese.

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Diesen Formulierungen möchte ich ganz entschieden widersprechen! Pseudo-Besitzer gibt es höchstens bei uid und gid, und auch da ist der Ausdruck "Pseudo…" nicht geeinet.

• der Besitzer ist im Linux-System echt, d.h. "persistent" eingerichtet

Letzteres stimmt, aber im Windows-System sind die damit gemappten SIDs "Kartei-Leichen". Darauf sollte sich "Pseudo" beziehen. Ob das ein guter Begriff ist, kann man sich gerne drüber streiten, vielleicht wäre "Phamtom-Besitzer-SIDs" besser.

... Er hat zwar keinen Namen, ...

Eben, und noch nicht mal einen namenlosen Account-Eintrag in der Windows-Registry, deshalb Pseudo-, Phantom- oder was auch immer.

Also ist er "persistent" und nicht "transient" und damit nichts von "Pseudo…"

Es gibt auch persistente Pseudos, oder vielleicht besser Phantome.

Es ist IMO genau so, wie ich geschrieben habe, und die von Tuxera gewählte Formulierung default user mapping ist gut und trifft genau den Sachverhalt!

Bisher habe ich diese Formulierung nur in der Mount-Terminal-Meldung gesehen. Oder hast Du sie schon mal in der Doku gefunden? Das "default" bezieht sich da jeweils auf das Default-Verhalten von permissions bzw. acl, und somit haben wir 2 Defaults nebeneinander, die vielleicht ähnlich sind, aber nicht dieselben, und die schon mal gar nicht das Default-Verhalten von NTFS-3G allgemein, also Standard ohne Spezial-Optionen, beschreiben.

Wie du siehst, habe ich inzwischen noch einiges an meinen Formulierungen gefeilt.

Ehrlich gesagt, ich käme mit der jetzigen Struktur des Kapitels "Echte (persistente) Linux-Dateirechte" überhaupt nicht zurecht, wenn ich das das erste Mal lesen würde. Aber jeder hat wohl so seine eigene Art, Dinge in einer Struktur abzubilden. Da hab' ich dann leider Pech gehabt mit der vom mir vorgeschlagenen Struktur. Außerdem wäre ich überfordert von der Menge an Text, wenn ich das als Einsteiger das erste Mal lesen würde. worin ich das Ziel der Verschlankung nicht wirklich realisiert sehe.

völlig einverstanden! Wir schreiben keine Dissertation, ...

Naja, die jetzige Ausprägung des Kapitels "Echte (persistente) Linux-Dateirechte" erzeugt bei mir schon genau diese Assoziation ... und der Teil, der die Nutzung und Konfiguration des UserMappings erklärt, wird ja wohl auch noch was länger. Hab' ja schon angedeutet, wo da die Tücken verborgen sind.

Max-Ulrich_Farber schrieb:

Ich will jetzt nochmal mit etwas mehr Gelassenheit antworten:

Ja gute Idee, und ich gebe zu, die fällt mir auch nicht leicht.

default user mapping ist das User-Mapping wie es stattfindet, wenn keine weiteren Vorgaben dazu kommen. So wird "Default…" häufig gebraucht. Das ist wohl verständlich. Der Treiber wählt sich "per default" für das Mapping selbst geeignete SIDs.

Nun kommt noch folgendes hinzu (ein besonderer "Service" des Treibers): Wenn der Treiber eine UserMapping-Datei findet, dann wird dadurch auch dann ein User-Mapping ausgelöst, wenn keine der Optionen permissions oder acl vorliegt. Und weil er dann nicht weiß, welche der beiden Optionen er dafür wählen soll, nimmt er in diesem speziellen Fall eben acl. Das ist alles!

Ich nehme an, Du meinst, er wählt / nimmt SIDs für das Mapping, wie es auch die Option acl (aber auch permissions) veranlassen würde.

Der Begriff könnte aber auch mit dem Verfahren von NTFS3 als vergleichbar angesehen und verwechselt werden, wo das Mapping ja tatsächlich per default stattfindet. Also wie gesagt, wenn Du den unbedingt verwenden willst, dann definiere ihn bitte ganz genau im Artikel.

Das stimmt so nicht. Bei NTFS3 wird gar nichts gemappt.

Natürlich wird da gemappt, in dem Fall halt mit irgendwelchen Bits, die irgendwo abgelegt sind. NTFS-3G nimmt halt die SID-Form dafür. Bei der ganzen Sache geht es ja nicht darum, irgendwelche Besitzer / Benutzer zu definieren, zu registrieren und zu mappen, sondern lediglich um die persistente "Registrierung" von Dateirechten. Diese Dateirechte beziehen sich nun mal immer auf Besitzer / Benutzer, und dafür braucht es Besitzerkennungen, an die diese Rechte gekoppelt sind. Es muss also für jedes Dateisystem-Objekt genaugenommen ein Mapping zwischen Besitzkennung und Recht erzeugt, verwaltet und (hier) persistent abgelegt werden. NTFS-3G wählt dafür als Ort die von Windows definierten ACLs (mit Kennungen die Windows weil unbekannt links liegen lässt und ignoriert) und NTFS3 wählt uns noch unbekannte und für Windows verborgene Orte dafür (und wie die genutzten Benutzer-Kennungen intern aussehen, wissen wir auch nicht).

Jetzt sind wir aber hier genau an der Stelle, wo wir auch in den Themen Symlinks, UDisks und Mount waren, nämlich bei den internen technischen Methoden, die zur Ausführung / Realisierung der gewünschten Leistungsmerkmale gebraucht werden. Im hiesigen Fall – Leistungsmerkmal: persistente Registrierung von Datei-Rechten – nennt sich die interne technische Methode Mapping. Die ist für den Benutzer von außen zunächst erst mal irrelevant, aber dennoch willst Du den Artikel genau danach strukturieren. Solange er nur die Optionen permissions oder acl verwendet, muss er von der technischen Methode Mapping (hier mit Phamtom-Entitäten, und wie sie parallel schadlos bzgl. der Windows-Rechteverwaltung abgelegt werden) überhaupt nichts wissen. Es geht ihm nur um die Dateirechte, die er persistent abgelegt haben will.
Erst im Fall von UserMapping (besser wäre eigentlich OwnerMapping) muss er sich mit dem Mapping zwischen real existierenden Windows- und Linux-Entitäten auseinandersetzen. Außerhalb davon ist der Begriff Mapping, egal ob "Default" oder nicht, aus Benutzersicht völlig irrelevant und uninteressant, und deshalb IMHO nicht zur Gliederung des Kapitels "Echte (persistente) Linux-Dateirechte" geeignet. Der von mir geprägte Begriff "Pseudo/Phantom-Besitzer" muss im Artikel nirgendwo erscheinen, solange man nicht die technische Realisierung der Leistungsmerkmale mit erklären will. Er diente nur als erklärendes Stichwort in der von mir vorgeschlagenen Gliederung.

Bei NTFS3 findet also überhaupt kein User-Mapping statt, nicht default und nicht mit Vorgaben.

Und genau genommen findet es auch unter den Optionen permissions und acl nicht statt, da überhaupt keine wirklichen "User" referenziert werden, mit denen gemappt werden könnte. Es gibt nur Phantom-Kennungen, die ersatzweise in den ACLs für die echten nur in Linux existierenden Benutzerkennungen verwendet werden.

Nebenbei passt das auch sprachlich: "default" bedeutet "fehlend", d.h. wenn weitere Vorgaben fehlen.

Ja interessant, dass wir es im Deutschen eher mit "Standard" übersetzen.

Jetzt zum Schluss noch eine Frage an den Experten kB:

Kennst Du ein einfaches Verfahren, um die SID zu ermitteln? Wenn man eine UserMap-Datei von Hand erstellen will, dann braucht man diese.

Unter Linux:

• ntfssecaudit

• ntfsusermap

Unter Windows:

• Usermap.exe oder so ähnlich, kann man irgendwo bei Tuxera / Github herunterladen.

Ich komme (leider) nicht umhin, jetzt Sprachstudien zu treiben. Es tut mir Leid, im ganz echten Sinne.

Für Mapping finde ich folgende Definition:

Mit Mapping in der Informatik ist der Prozess gemeint, bei dem Daten von einem Format oder System in ein anderes überführt werden. Es ist also eine Art Übersetzung zwischen unterschiedlichen Datenmodellen oder Datenstrukturen.

Und genau dies findet beim User-Mapping von NTFS-3G statt: Eine Überführung von der Linux-Struktur in die Windows-Struktur. Der Begriff wird also absolut korrekt verwendet. Und das geschieht bei NTFS3 nicht. Dass die Dateirechte irgendwie als "Metadaten" festgehalten werden, ist klar. Wie sollten sie sonst persistent sein? Aber sie werden dazu nicht in eine andere Datenstruktur überführt bzw. abgebildet.

…ein Mapping zwischen Besitzkennung und Recht…

und dies ist eben nach obiger Definition kein "Mapping", sondern eine Zuordnung. Für mich (und gemäß obiger Definition) sind das zweierlei Dinge. Wenn Du unter "Mapping" nichts anderes als "Zuordnung" oder auch "Koppelung" verstehst, dann gibt es natürlich bei NTFS3 auch "Mapping", denn die Rechte müssen ja irgend einem Bit oder ähnlich zugeordnet werden. Aber dieses Verständnis entspricht, wie gesagt, nicht der Definition.

Ich nehme an, Du meinst, er wählt / nimmt SIDs für das Mapping, wie es auch die Option acl (aber auch permissions) veranlassen würde.

Ich meine, er geht in jeder Hinsicht ganz genau so vor, wie wenn beim Einbinden die Option acl gesetzt wäre. Ob man noch zusätzlich die Option acl setzen würde oder nicht, ändert in diesem Fall gar nichts. Wenn du willst, die Option acl wird transparent gesetzt. – Doch ob er permissions oder acl wählt, spielt für das Mapping der Benutzer (noch) keine Rolle, das macht erst bei dem Mapping der Zugriffsrechte einen Unterschied. Und das ist "Teil 2" des User-Mappings. Weil aber die Zugriffsrechte mit den Benutzern korrelieren, kann man es bei de Bezeichnung "User-Mapping" belassen.

Solange er nur die Optionen permissions oder acl verwendet, muss er von der technischen Methode Mapping (hier mit Phamtom-Entitäten, und wie sie parallel schadlos bzgl. der Windows-Rechteverwaltung abgelegt werden) überhaupt nichts wissen.

Dem stimme ich nicht zu! Wie willst du denn sonst erklären, dass in Linux die Dateirechte einer Datei kaputt gehen, wenn man dieser in Windows einen Besitzer (evtl. auch den gleichen) zuordnet, und genau so auch umgekehrt? Und wie willst du erklären, dass default user mapping und UserMapping-Datei einander ebenfalls kaputt machen? In beiden Fällen funktioniert eben das User-Mapping nach genau dem gleichen Schema, nur dass dafür nicht die gleichen SID verwendet werden. Abgesehen davon gibt es eben keinen Unterschied.

Erst im Fall von UserMapping (besser wäre eigentlich OwnerMapping) muss er sich mit dem Mapping zwischen real existierenden Windows- und Linux-Entitäten auseinandersetzen.

"User-Mapping" ist besser, denn es werden nicht nur uid undgid des Besitzers auf einen SID gemappt, sondern auch diejenigen jedes Benutzers, der zugreifen möchte und vielleicht durch die Zugriffsrechte darin eingeschränkt wird. Und beim default user mapping muss man eben ein "Mapping zwischen real existierenden Windows- und Linux-Entitäten" vermeiden (s.o.), und der Benutzer muss da aufpassen! Zum Begriffspaar "real existierend" gegenüber "Phantom" oder "Pseudo" komme ich noch.

Und genau genommen findet es auch unter den Optionen permissions und acl nicht statt, da überhaupt keine wirklichen "User" referenziert werden, mit denen gemappt werden könnte. Es gibt nur Phantom-Kennungen, die ersatzweise in den ACLs für die echten nur in Linux existierenden Benutzerkennungen verwendet werden.

Auch das kann ich so keinesfalls stehen lassen! Das User-Mapping findet eben nur unter den Optionen permissions oder acl statt, bei acl evtl. auch transparent. Was "Phantomkennungen" im Gegensatz zu "echten nur in Linux existierenden Benutzerkennungen" sind, verstehe ich nicht.

Lieber UlfZibis, ich habe dich noch nie gesehen. Ich kenne auch deinen Bürgerlichen Namen nicht, ich kenne von dir nur Wiki-Artikel und Diskussionsbeiträge. Aber bist du deshalb ein "Pseudomensch" oder ein "Phantom"? Du existierst doch real, nur kann ich dich in meinen Bekanntenkreis nicht einordnen.

Ein anderes Beispiel (fiktiv): Ich habe 2 Laptops A und B mit je einem Windows-System (kein Linux und kein NTFS-3G dabei). Auf den Laptops sind verschiedene Benutzer mit verschiedenen Namen eingerichtet. Ich verwende einen mit NTFS formatierten USB-Stick zum Datenaustausch zwischen A und B. Mit beiden Laptops werden dabei abwechselnd Dateien auf den Stick geschrieben. Laptop A kennt die User von B nicht beim Namen, sie sind ja auf A nicht angemeldet. Genau so umgekehrt. Beim Lesen von dem Stick erfährt A von den B-Usern nur ihre SID, und genau so umgekehrt. – Frage: Welche Benutzer existieren nun real und welche sind "Pseudo" oder "Phantome"? Im NTFS-Dateisystem des Sticks sind sie alle gleich real, dem Stick ist es egal, woher sie stammen. Hauptsache, sie entsprechen den Regeln des Dateisystems.

Ganz genau so ist es auch mit dem User-Mapping von NTFS-3G. Die Dateien und ihre Metadaten sehen genau so aus, wie wenn sie in einem anderen Windows-System mit anderen Namen geschrieben worden wären. Im NTFS-Dateisystem des Sticks ist an nichts zu erkennen, dass sie über NTFS-3G geschrieben wurden. Die Dateien und ihre Metadaten sind genau so real wie die von einem Windows-System geschriebenen. Pseudo-User oder Phantome gibt es nicht, nur eben User, deren Namen das Windows-System nicht kennt.

Ganz anders ist es nur bei den ohne User-Mapping mittels uid &Co eingerichteten transienten Rechten. Aber "Phantome" sind nicht einmal diese, denn sie sind ja bis zum Aushängen der Partition durchaus real wirksam. Aber eben nur vorübergehend - "transient".

So, das war jetzt ein "schwerer Brocken". Jetzt brauche ich ein Bier!

Prost! – Max-Ulrich

P.S.

zu guter Letzt will ich mich noch bedanken für die Hinweise zum Ermitteln der SID! Danke UlfZibis!

Max-Ulrich_Farber schrieb:

…ein Mapping zwischen Besitzkennung und Recht…

und dies ist eben nach obiger Definition kein "Mapping", sondern eine Zuordnung.

An der Stelle muss ich Dir Recht geben. Da hatte ich den Begriff etwas allgemeiner gebraucht, als er definiert ist.
Kommt wohl daher, dass es in der Bibliothek der Programmiersprache Java eine Klasse namens "Map" gibt, die eben tatsächlich Äpfel mit Schrauben mappt. Auch eine sogenannte "key value map", z.B. die Windows-Registry, müsste dann eigentlich "key value assignment" heißen. Und guck' mal hier, da steht die Übersetzung "mapping" über "assignment".

... dann gibt es natürlich bei NTFS3 auch "Mapping", denn die Rechte müssen ja irgend einem Bit oder ähnlich zugeordnet werden.

Nun ja, die Bits müssen ja in einer dem NTFS-Dateisystem konformen Struktur abgelegt werden. Auch wenn wir sie (noch) nicht kennen, findet sicher ein Mapping in diese statt. Und da dies bei NTFS3 immer ohne weitere Optionen – also "fehlend" – passiert, ist das für mich ein "Default-Mapping". Bei NTFS-3G ist keins der 3 angebotenen Default.

Ich nehme an, Du meinst, er wählt / nimmt SIDs für das Mapping, wie es auch die Option acl (aber auch permissions) veranlassen würde.

Ich meine, er geht in jeder Hinsicht ganz genau so vor, wie wenn beim Einbinden die Option acl gesetzt wäre. Ob man noch zusätzlich die Option acl setzen würde oder nicht, ändert in diesem Fall gar nichts. Wenn du willst, die Option acl wird transparent gesetzt.

Ja so war es gemeint von mir (und auch nur am Rande wichtig).

Solange er nur die Optionen permissions oder acl verwendet, muss er von der technischen Methode Mapping (hier mit Phamtom-Entitäten, und wie sie parallel schadlos bzgl. der Windows-Rechteverwaltung abgelegt werden) überhaupt nichts wissen.

Dem stimme ich nicht zu! Wie willst du denn sonst erklären, dass in Linux die Dateirechte einer Datei kaputt gehen, ...

Stimmt, wenn man das erklären will, ist das notwendig, geht aber dann in Richtung "Dissertation".

Bzgl. der anderen Aspekte rund um NTFS-3G hatten wir uns darauf geeinigt. die technischen Erklärungen wegzulassen, und primär nur Verwendungsempfehlungen anzugeben. Warum hier jetzt wieder doch nicht? Ich habe nichts gegen die technischen Erklärungen, doch sollten sie IMHO nicht die Gliederung des Artikels bestimmen und bezeichnen, sondern eher optional separat in Experten-Boxen untergebracht werden. Das erinnert mich an die "5 biologischen Naturgesetze" von Dr. Hamer. Es gab dann Leute, die seine Lehre in Bücher geschrieben haben. Diese waren nach Organen gegliedert. Dem Dr. gefiel das nicht, denn er hielt die Gliederung nach Gewebstypen für korrekter und sein einziges Buch war auch so gegliedert. In letzterem fand sich der Laie aber nicht so gut zurecht, und so wurden die Bücher der "Abschreiber" besser verkauft.
Also wenn man hier alle technischen Erklärungen korrekt und vollständig in dem Artikel unterbringen will, wäre es vielleicht besser, die Original-Doku 1:1 zu übersetzen, da die sicher schon mehrfach revisioniert wurde.

Erst im Fall von UserMapping (besser wäre eigentlich OwnerMapping) muss er sich mit dem Mapping zwischen real existierenden Windows- und Linux-Entitäten auseinandersetzen.

"User-Mapping" ist besser, denn es werden nicht nur uid undgid des Besitzers auf einen SID gemappt,

... aber vornehmlich. Es geht um den Datei-Besitz (Owner), der gemappt wird. Benutzer-Mapping würde bedeuten, Die Linux- mit Windows-Benutzerkonten zu mappen. Und da letztere im Fall von permissions und acl gar nicht existieren, sind die von NTFS-3G kreierten SIDs (aus Windows-Sicht, denn nur da sind sie sichtbar) eben Phantom-SID-Kennungen, da sie nichts kennzeichnen. Also so ist da meine Definition.

Das User-Mapping findet eben nur unter den Optionen permissions oder acl statt, ...

Du meinst wohl das "Default-User-Mapping".

Lieber UlfZibis, ich habe dich noch nie gesehen. Ich kenne auch deinen Bürgerlichen Namen nicht, ich kenne von dir nur Wiki-Artikel und Diskussionsbeiträge. Aber bist du deshalb ein "Pseudomensch" oder ein "Phantom"? Du existierst doch real, nur kann ich dich in meinen Bekanntenkreis nicht einordnen.

Guter Vergleich. Deshalb habe ich ja auch eine Real-Kennung, und eben keine Phantom-Kennung.

Ein anderes Beispiel (fiktiv): Ich habe 2 Laptops A und B mit je einem Windows-System (kein Linux und kein NTFS-3G dabei). Auf den Laptops sind verschiedene Benutzer mit verschiedenen Namen eingerichtet. Ich verwende einen mit NTFS formatierten USB-Stick zum Datenaustausch zwischen A und B. Mit beiden Laptops werden dabei abwechselnd Dateien auf den Stick geschrieben. Laptop A kennt die User von B nicht beim Namen, sie sind ja auf A nicht angemeldet. Genau so umgekehrt. Beim Lesen von dem Stick erfährt A von den B-Usern nur ihre SID, und genau so umgekehrt. – Frage: Welche Benutzer existieren nun real und welche sind "Pseudo" oder "Phantome"? Im NTFS-Dateisystem des Sticks sind sie alle gleich real, dem Stick ist es egal, woher sie stammen. Hauptsache, sie entsprechen den Regeln des Dateisystems.

Das sind dann reale Kennungen, denn die dazugehörigen Windows-Benutzerkonten existieren ja. Allerdings kann das jeweils andere System nicht feststellen, ob es sich um Phantome handelt. Und wenn dann bestimmten Dateien Lese- und Schreibrechte nur für den Besitzer eingetragen sind, kann das jeweils andere System die auch nicht öffnen. Um dem vorzubeugen, vergibt NTFS-3G bei permissions ja auch zusätzlich alle Rechte für die Windows-Jeder-SID. Im Fall von NTFS-3G kann Windows allerdings sogar feststellen, dass es sich um Phantome handelt, denn die von NTFS-3G kreierten SIDs sind (angeblich) so aufgebaut, dass sie Windows so nie selbst erzeugen würde.
Man könnte jetzt noch einwerfen, dass bei NTFS-3G die damit gemappten Linux-Benutzerkonten ja existieren. Das lässt sich vergleichen mit dem Fall, dass ich mir einen französischen Pass-Rohling besorge, und da meine deutsche Adresse und auch eine ID nach deutschem Muster und als ausstellende Behörde ein Amt statt eine autorité eintrage. Im französischen Melderegister bin ich dann dennoch ein Phantom.

So, das war jetzt ein "schwerer Brocken". Jetzt brauche ich ein Bier!

Prost! – Max-Ulrich

Sei Dir gegönnt. Meins ist schon fast leer

Prost – Ulf

Max-Ulrich_Farber schrieb:

[…] Bei NTFS3 wird gar nichts gemappt. Das habe ich untersucht und auch mit einer Bildschirm-Kopie aus Windows aufgezeigt. Es gibt in Windows für die Linux-Benutzer keine SID, die Linux-Dateien sind in Windows völlig herrenlos. Bei NTFS3 findet also überhaupt kein User-Mapping statt, nicht default und nicht mit Vorgaben.

M.E: muss man hier die Begriffe „Benutzer“ und „Besitzer“ sauber unterscheiden:

• „Benutzer“ meint zunächst einmal ein Anmeldekonto. Das gibt es unter Windows wie unter Linux. Ein realer Mensch meldet sich am Betriebssystem unter Verwendung eines solchen Anmeldekontos an und erhält, wenn er alle Prüfungen besteht, die per Anmeldekonto erlaubten Arbeitsmöglichkeiten.

• „Besitzer“ einer Datei gibt es nur unter Linux, bei Windows sind immer alle Dateien herrenlos, egal, ob sie unter Windows oder unter Linux angelegt wurden.

• Linux kennt dann auch noch für jede Datei sog. Dateirechte für den Besitzer, eine benannte Gruppe und alle anderen.

• Windows kennt solche an den Dateibesitzer gebundenen Rechte nicht, weil es schon den Begriff Dateibesitzer nicht kennt.

• Windows hat aber ein über die SIDs verwaltetes Rollensystem. Jede Rolle kann keinen, einen oder mehrere Benutzer (im Sinne Anmeldekonto) als Mitglied haben; das ähnelt den Gruppen unter Linux wie auch POSIX-ACLs, ohne solchen genau zu entsprechen.

• Jeder Datei kann unter Windows mehrere Rollen zugewiesen werden oder solche werden aus der Hierarchie geerbt. Ein Benutzer, welcher Mitglied einer Rolle ist, darf mit der Datei das machen, was sie für diese Rolle vorsieht (Lesen oder Schreiben oder gar nichts).

Mein Eindruck:

• Beide Treiber legen für jede unter Linux im NTFS-Dateisystem vertretenen Besitzer/Benutzer von Linux und jede vertretene Gruppe von Linux unter Windows verwendbare Rollen bzw. SIDs an; ntfs3 macht es grundsätzlich, ntfs-3g optional.

• Einer unter Linux angelegten Datei werden die zutreffenden SIDs zugeordnet.

• Unter Windows sind die von Linux aus erschaffenen Rollen real und können normal verwendet werden. (Was zu prüfen wäre.)

• Nur ntfs-3g scheint darüber hinaus auch noch eine Zuordnung Windows-Anmeldekonto ←→ Linux-Anmeldekonto herzustellen und nur dieses ist das "User-Mapping".

kB schrieb:

• „Besitzer“ einer Datei gibt es nur unter Linux, bei Windows sind immer alle Dateien herrenlos, egal, ob sie unter Windows oder unter Linux angelegt wurden.

Nein, das stimmt nicht. Unter Windows gibt es sehr wohl einen Besitzer. An den Besitzer unter Windows ist vor allem das Dateirechte-Verwaltungsrecht gebunden. Dateirechte-Verwaltungsrechte gibt es die folgenden

• Rechte lesen

• Rechte ändern

• Besitz übernehmen/ändern

Ein Standardbenutzer bekommt über den Besitzerstatus die Dateirechte-Verwaltungsrechte

• Rechte lesen

• Rechte ändern

Ein weiterer Standardbenutzer der nicht Besitzer ist erhält dagegen nur das Dateirechte-Verwaltungsrecht:

• Rechte lesen

Ein Administrator-Konto erhält beim Erstellen einer Datei oder eines Ordners die Dateirechte-Verwaltungsrechte:

• Rechte lesen

• Rechte ändern

• Besitz übernehmen/änern

Die "Dateirechte-Verwaltungsrechte" sind AFAIK einer der wesentlichen Unterschiede zwischen POSIX-(Draft)-ACL und Windows-ACL.

Jedenfalls sind Dateien und Ordner unter Windows nicht "herrenlos".

LG, Newubunti

kB schrieb:

M.E: muss man hier die Begriffe „Benutzer“ und „Besitzer“ sauber unterscheiden:

Bis zu einem bestimmten Punkt eine schöne Zusammenstellung, aber schau mal hier: Windows Datei Besitzer ändern

Mein Eindruck:

Auch gut.

Aber:

• Unter Windows sind die von Linux aus erschaffenen Rollen real und können normal verwendet werden. (Was zu prüfen wäre.)

Was verstehst Du genau darunter? Nach meinem Verständnis sind Gruppen in Linux, wie z.B. disk, quasi Rollen. Wie soll so eine Rolle unter Windows verwendet werden können?

• Nur ntfs-3g scheint darüber hinaus auch noch eine Zuordnung Windows-Anmeldekonto ←→ Linux-Anmeldekonto herzustellen und nur dieses ist das "User-Mapping".

Nicht wirklich. Mit "User-Mapping" werden IMHO nur die Besitzer gemappt, theoretisch auch ungültige Phantom-Besitzer, also solche, für die es kein Konto gibt.

Ein Benutzer/Konto-Mapping erfordert IMHO 2 aktive Maschinen, die unter Nutzung entsprechender Kommunikation einen Linux-Benutzer auf einem Windowssystem als dort bekannter Benutzer Handlungsmöglichkeiten ermöglichen. Ein statischer Map-Eintrag auf einem Datenträger gibt das nicht her.

Ich arbeite wieder "von hinten nach vorne":

@kB:

„Besitzer“ einer Datei gibt es nur unter Linux, bei Windows sind immer alle Dateien herrenlos, egal, ob sie unter Windows oder unter Linux angelegt wurden.

Windows macht mich noch verrückt! Warum kann man dann mit "Eigenschaften - Sicherheit - sonstiges" (oder wie das genau heißt) einen Eigentümer für die Datei festlegen? Wozu dann das?

Windows kennt solche an den Dateibesitzer gebundenen Rechte nicht, weil es schon den Begriff Dateibesitzer nicht kennt.

Stimmt. Die Zugriffsrechte werden eben per ACL für alle Benutzer "individuell" oder gruppenweise festgelegt (deshalb bevorzuge ich ja "Benutzer-Mapping" gegenüber "Besitzer-Mapping").

das ähnelt den Gruppen unter Linux wie auch POSIX-ACLs, ohne solchen genau zu entsprechen.

Nur die letzteren habe ich, glaube ich, wirklich verstanden. Windows aber nicht wirklich bzw. wenigstens nicht ganz…

Jeder Datei kann unter Windows mehrere Rollen zugewiesen werden oder solche werden aus der Hierarchie geerbt. Ein Benutzer, welcher Mitglied einer Rolle ist, darf mit der Datei das machen, was sie für diese Rolle vorsieht (Lesen oder Schreiben oder gar nichts).

Genau so funktionieren ja AFAIK die ACL.

Nun zu "mein Eindruck". Da habe ich schon manches, was dort als "zu untersuchen" steht, untersucht:

Beide Treiber legen für jede unter Linux im NTFS-Dateisystem vertretenen Besitzer/Benutzer von Linux und jede vertretene Gruppe von Linux unter Windows verwendbare Rollen bzw. SIDs an; ntfs3 macht es grundsätzlich, ntfs-3g optional.

Das habe ich untersucht und das Windows-Ergebnis als Screenshot in meine Cloud gestellt. Ergebnis: NTFS-3G tut dies mittels User-Mapping (default oder nicht) genau so, und die "Rollen" =SID sind in Windows voll verwendbar. NTFS3 (und vermutlich auch NTFS-3G ohne das User-Mapping) tut das aber gar nicht. Die Linux-Dateien erscheinen in Windows splitternackt ohne jeder "Rolle" und ohne SID! (siehe Screenshot).

Einer unter Linux angelegten Datei werden die zutreffenden SIDs zugeordnet.

Genau so ist es beim User-Mapping von NTFS-3G, und was "entsprechend" bedeutet, ist halt jeweils verschieden: Bei default sind dies halt frei gewählte, beliebige, und bei einer Usermap-Datei diejenigen, die in Windows einem User gleichen Namens zugeteilt wurden. – Aber bei NTFS3 ist es eben nicht so.

Unter Windows sind die von Linux aus erschaffenen Rollen real und können normal verwendet werden. (Was zu prüfen wäre.)

Das habe ich schon (kurz, mit nur wenigen Beispielen) geprüft. Es ist so, ein Gegenbeispiel habe ich nicht gefunden (ich glaube, dafür gab es auch ein Screenshot, bin mir aber nicht mehr sicher).

Nur ntfs-3g scheint darüber hinaus auch noch eine Zuordnung Windows-Anmeldekonto ←→ Linux-Anmeldekonto herzustellen und nur dieses ist das "User-Mapping".

Klar, mit NTFS3 kann das somit ja gar nicht gehen. "User-Mapping" ist halt das Verfahren, mittels dessen NTFS-3G die in Windows verwendbaren SID für Linux verwendbar macht.

Mein Eindruck:

In den Metadaten ist irgendwo noch ein "freier Platz", in dem NTFS3 die Original-Linux-Dateirechte ablegen kann, ohne "Mapping" auf eine andere Struktur. Deshalb brauchen die an anderer Stelle abgelegten SID den Treiber NTFS3 gar nicht zu interessieren. Aber auch Windows nimmt die Linux-Dateirechte nicht zur Kenntnis. Ganz anders als bei NTFS-3G haben die beiden Rechtesysteme, die sich sowieso nicht lückenlos aufeinander abbilden lassen, gar nichts miteinander zu tun.

Wenn jemand eine Synchronisation von Dateirechten durchführen will, dann kann bzw. muss er dies von Hand tun, d.h. er muss in beiden Systemen bei jeder Datei dem User gleichen Namens entsprechende Rechte verleihen. Das muss ohne Probleme gehen – von Hand!

Wenn Jemand das aber in NTFS-3G genau so macht, dann macht er damit alles kaputt! Weil es aber jetzt den Treiber NTFS3 standardmäßig gibt, ist die Versuchung da, dies zu tun. Und man kann nur verstehen, warum man da Ungedeih produziert, wenn man das User-Mapping richtig verstanden hat.

Ich will es deshalb entgegen den Einsprüchen von UlfZibis bei meinem neuen Aufbau des Artikels (User-Mapping bzw. default user mapping von Anfang an erklären) belassen, weil auch das default user mapping schon schwerwiegende, sonst nicht verständliche Fallen beinhaltet. Alle, die das User-Mapping nicht verwenden oder gar nicht zwischen Linux und Windows hin und her wechseln wollen, oder auch alle, denen es zu kompliziert ist, haben ja jetzt den Kernel-Treiber NTFS3.

Durch den standardmäßigen Kernel-Treiber NTFS3 wird NTFS-3G nun zu einer Spezial-Anwendung, da darf die Erklärung wohl schon ein bisschen anspruchsvoller sein.

Jetzt schicke ich ’mal ab. Dann kann ich mich in Ruhe mit den Einwänden von UlfZubis befassen.

Danke, Newubunti! Jetzt verstehe ich manches besser. Oder meine das wenigstens. Du hast mich vor dem Wahnsinn bewahrt (hoffentlich nicht nur vorübergehend) – ein gutes Werk! 😉

@UlfZubis:

Ich glaube, wir reden die ganze Zeit von zwei verschiedenen Dingen: Ich rede von dem Dateisystem auf der NTFS-Partition, wie es real existiert. Und du redest davon, wie irgend ein – meist Windows- – System dieses "empfindet" bzw., wenn du das lieber willst, interpretiert. Das sind zwei völlig verschiedene Blickwinkel.

@UlfZubis:

Ich gehe wieder von hinten nach vorne vor. Ich hoffe, Newubunti sieht darin keinen Beweis dafür, dass es ihm doch nicht gelungen ist, mich vor dem Wahnsinn zu bewahren! Vielleicht muss es Newubunti nach diesem Post halt nochmal versuchen – bitte!

Ein Benutzer/Konto-Mapping erfordert IMHO 2 aktive Maschinen, die unter Nutzung entsprechender Kommunikation einen Linux-Benutzer auf einem Windowssystem als dort bekannter Benutzer Handlungsmöglichkeiten ermöglichen. Ein statischer Map-Eintrag auf einem Datenträger gibt das nicht her.

Nein, nochmal nein! Ob eine, zwei oder 15 Maschinen ist dafür völlig irrelevant! Gar kein Nutzer, bekannt oder nicht, wird gemappt, sondern Dateirechte – UID, GID, UMASK, und ggf. noch POSIX-ACL – werden auf einen SID gemäß der Windows-Richtlinien gemappt. Dazu braucht es überhaupt kein Windows-System, und was ggf. dann ein solches damit anfangen kann, steht auf einem ganz anderen Blatt! Denke an einen USB-Stick mit NTFS: Den kannst du in verschiedene Windows- oder auch Linux-Systeme reinstecken. Was die dann damit anfangen können ist ganz verschieden. Aber der Stick ist immer der gleiche!

Nicht wirklich. Mit "User-Mapping" werden IMHO nur die Besitzer gemappt, theoretisch auch ungültige Phantom-Besitzer, also solche, für die es kein Konto gibt.

Auf dem Stick gibt es gar keine Besitzer, keine gültige oder Phantome ohne Konto. Davon weiß der Stick gar nichts, auf ihm gibt es nur Dateien mit SID. Und wenn die SID den Regeln entsprechen, ist alles ok. Alles andere interessiert den Stick gar nicht, interessiert aber vielleicht das jeweilige System, in das der Stick gesteckt wird. Aber davon reden wir noch gar nicht. Zunächst geht es nur um das Mapping von Linux-Dateirechten auf SID. Das entspricht genau der Definition: Überführen von einer Struktur in eine andere.

Was verstehst Du genau darunter? Nach meinem Verständnis sind Gruppen in Linux, wie z.B. disk, quasi Rollen. Wie soll so eine Rolle unter Windows verwendet werden können?

Versteht Ihr vielleicht den Begriff "Rolle" ganz verschieden: Einmal als "Dokument-Rolle", als Zusammenstellung von Eigenschaften, und einmal als "Rolle" wie im Theater für einen Schauspieler?

Mein Eindruck: (von kB)

Auch gut.

Dazu habe ich schon Stellung genommen. Und zum Passus davor hat das Newubunti schon getan.

L.G.