staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

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).

Also wenn ich unter Ubuntu - egal ob mit ntfs-3g oder ntfs3 - über GUI ohne weitere Optionen einbinde, dann werden neue Dateien immer mit dem Windows Besitzer Administratoren (SID: S-1-5-32-544) angelegt. Das lässt sich auch mittels

sudo ntfssecaudit /meine/Datei/auf/NTFS 

anzeigen. D.h. standardmäßig findet bereits ein Mapping/Interpretation vom Windows Benutzer Administratoren auf root statt bzw. ein Mapping von SID S-1-5-32-544 auf uid 0. Es wird von Ubuntu aus der Windows Besitzer Administratoren angelegt, aber gleichzeitig von Ubuntu aus, als root interpretiert.

Unter Windows empfehle ich zur Betrachtung eine administrative Powershell zu öffnen und dann dort auf das Laufwerk mit der NTFS-Partition wechseln, und dann:

get-childitem | get-acl 

Dann bekommt man die Berechtigungen aller Objekte einschließlich des Besitzers im aktuellen Verzeichnis angezeigt.

LG, Newubunti

Eben war ich noch einkaufen, und da fiel es mir – um mit Otto Waalkes zu sprechen – wie Schuppen aus den Haaren (obwohl der davon inzwischen ja genau so wenig hat wie ich…).

Der Kernpunkt unseres Missverständnisses ist das "User" bei dem "User-Mapping". Wenn man das verscheiden versteht, dann kann man sich nicht näher kommen. – Ich denke dabei an das "Mapping" von Linux-Dateirechten auf einen SID. Das entspricht genau der schon zitierten Definition von Mapping (nochmal):

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.

Gemappt werden so Daten, aber keine User. Es heißt nun aber ’mal "User"-Mapping, und der Begriff suggeriert Anderes. Bei meinem Verständnis braucht man gar keine zwei User, sondern nur zwei Datenstrukturen - die von Linux und die von Windows. Und letztere wird eben auf dem Stick verwendet, egal, was mit dem Stick sonst noch passiert. Das heißt, wenn die Datenstruktur von Windows verwendet wird, dann muss eben ein Mapping stattfinden, egal, ob noch ein anderes System oder ein zweiter User beteiligt ist oder nicht.

Aber ein "User"-Mapping ist das nicht. Bei diesem Begriff wird eben suggeriert, dass es zwei User (bzw. Accounts) geben muss, und dass der eine auf den anderen überführt wird. Das ist ein völlig anderes Verständnis und mit dem obigen schwer oder gar nicht in Einklang zu bringen. Ich würde es vielleicht mit "Synchronisation zweier User-Accounts" umschreiben. Ein solches "Mapping" findet natürlich nur dann statt, wenn es zwei zu synchronisierende User-Accounts gibt, und dazu braucht man natürlich 2 Systeme. Das "default user mapping" ist in diesem Sinne natürlich kein echtes "User"-Mapping, weil es den zweiten User gar nicht kennt (oder es gar keinen gibt), der ist dann natürlich ein "Phantom". Das alles ist in sich völlig logisch.

Das default user mapping ist damit auf jeden Fall eine in sich widersprüchliche oder missverständliche Bezeichnung. "Mapping" im ersten Sinne ist mit Usern gar nicht möglich, sondern nur mit Daten. Auch nicht mit User-Accounts, denn die kennt der Stick gar nicht. Also ist es kein "User"-Mapping. Versteht man es aber im zweiten, nicht der obigen Definition entsprechenden Sinn, dann funktioniert es erst, wenn zwei User mit ihren Accounts beteiligt sind, oder es muss eben ein zweiter User als Phantom angenommen werden. Also wieder falsch, denn ein Mapping im eigentlichen, informatischen Sinn ist das ja nicht.

Jeder von uns beiden bleibt in seiner Denkweise, die in sich ja voll logisch und verständlich ist, findet aber die Denkweise des anderen kompliziert und unlogisch, weil er begrifflich von ganz anderen Voraussetzungen ausgeht.

Obwohl es wirklich schwierig war, bin ich doch froh, dass das Problem der Begriffe und der Verständigung jetzt so massiv aufgetreten ist. Denn die Auffassung von UlfZibis liegt wirklich nahe, und wenn man so an meine Darstellung ’rangeht, dann wird diese absolut unverständlich. Ohne vorherige Klärung der verwendeten Begriffe geht es so nicht.

Ich werde mich da nochmal reinknieen müssen. Da komme ich nicht drum herum. Sonst würde es sicher viele geben, die die Begriffe – wie auch UlfZibis – anders verstehen und meine Darstelling deshalb unverständlich finden. Und das muss vermieden werden.

UlfZibis, können wir uns so einig werden? Dann hat uns ja Otto Waalkes wieder mal geholfen! 🤣

Beste Grüße!

@Newubunti:

Danke, das nützt mir viel. Ich bin eben leider kein Windows-Fachmann (ich weiß auch nicht, ob ich das psychisch verkraften könnte… 🙄 ), und deshalb habe ich meine Untersuchungen dort in der GUI gemacht. Und da sieht man zwar vieles, aber doch nicht alles.

Trotzdem habe ich gesehen, dass sich die Ergebnisse bei NTFS-3G und bei NTFS3 grundsätzlich unterscheiden, und dass bei NTFS3 ein Mapping der Linux-Dateirechte auf eine SID offenbar nicht stattfindet. Ein Mapping (ich würde da besser Zuordnung sagen) von "Administrator" auf "Root" findet schon statt, aber das ist ja etwas völlig Anderes!

Mein Gott, wie viel Zeit haben wir jetzt damit zugebracht (nicht nur wir beide), einander klar zu machen, dass wir unter "User-Mapping" etwas ganz Verschiedenes verstehen, und zwar ganz von Anfang an!

Max-Ulrich_Farber schrieb:

@Newubunti:

Danke, das nützt mir viel. Ich bin eben leider kein Windows-Fachmann (ich weiß auch nicht, ob ich das psychisch verkraften könnte… 🙄 ), und deshalb habe ich meine Untersuchungen dort in der GUI gemacht. Und da sieht man zwar vieles, aber doch nicht alles.

Du kannst auch in der GUI im Reiter "Sicherheit" auf "Erweitert" klicken. Dann siehst Du oben den "Windows Besitzer". Hilfreich ist in diesem Fenster auch der Reiter "Effektiver Zugriff". Da kann man sich dann einen Benutzer oder eine Gruppe auswählen und alle Rechte anzeigen lassen, die für das betreffende Objekt bestehen.

LG, Newubunti

Ganz genau so habe ich es gemacht und dann die Screenshots in meine Cloud gestellt. So bin ich ja zu meinen Informationen gekommen. Den Reiter "Effektiver Zugriff" hatte ich allerdings nicht entdeckt, aber das mir Wichtige auch so gefunden.

Aber ich glaube, ich muss da jetzt nicht weiter im Windows-Dschungel forschen, alles im Moment Wesentliche habe ich gefunden. Jetzt geht es erst ’mal darum, das wirklich blöde Missverständnis bei der ebenfalls blöden Bezeichnung default user mapping, die ich ja (zu meiner Entlastung) nicht selbst erfunden habe, zu beseitigen.

Ganz klar, wenn man der Bezeichnung folgend denkt, dass da User gemappt werden, versteht man nie was gemeint ist. Es werden eben keine User gemappt, sondern es werden nur User-Kennungen und Dateirechte und evtl. auch noch POSIX-ACL von einer Daten-Struktur in eine andere übertragen. Und in der Informatik nennt man diesen Vorgang eben "Mapping". Mehr nicht, und wer einen User sucht, der da gemappt wird – auf was denn sonst soll der denn gemappt werden als auf einen anderen User? – der kann das ganze nur kompliziert und unverständlich finden. Denn genau das findet eben nicht statt!

Ich muss das Ganze nochmal anders schreiben, und die missverständliche Bezeichnung "Default-User-Mapping" zumindest aus den Überschriften herausnehmen. Danke UlfZibis, dass du mich so hartnäckig auf dieses naheliegende Missverständnis hingewiesen hast!

L.G.

EDIT

ich habe jetzt den Abschnitt Die Optionen permissions und acl neu verfasst und anders gegliedert. Dabei habe ich auch gezielt auf mögliche Missverständnisse hingewiesen. Ich hoffe, er ist dadurch verständlicher geworden. Ein "Feinschliff" steht natürlich noch aus!

Max-Ulrich_Farber schrieb:

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.

Geht in der Powershell nicht

get-localuser | select name,sid 

bzw.

get-localgroup | select name,sid 

?

LG, Newubunti

Max-Ulrich_Farber schrieb:

ich habe jetzt den Abschnitt Die Optionen permissions und acl neu verfasst und anders gegliedert. Dabei habe ich auch gezielt auf mögliche Missverständnisse hingewiesen. Ich hoffe, er ist dadurch verständlicher geworden. Ein "Feinschliff" steht natürlich noch aus!

Ja habe ich gesehen. Der Text lässt sich jetzt flüssig lesen, und mir fielen auch weder Widersprüche noch Fragen auf, da Du den Begriff default_user_mapping nun klar definiert hast. Allerdings findet ein solches eher zwischen den Gruppen/Rollen "Administratoren" und "root" statt (In Linux existiert ja nicht nur der Benutzer, sondern auch die gleichnamige Gruppe root). Das war mir bekannt, ich hab's aber weggelassen, eben um dem "keine Dissertation" gerecht zu werden. Das, worauf es hier ankommt, würde ich eher als "Default-Permissions-Mapping" bezeichnen.

Dennoch verstehe ich nicht, welchen Sinn es haben soll, den Optionen permissions und acl der Zwischenebene "Die Optionen permissions und acl" unterzuordnen, statt alle 3 Möglichkeiten der "persistenten Rechteablage" nebeneinander dem Haupt-Kapitel direkt unterzuordnen. Das "Default-Mapping" bzgl. der Administratoren-Rechte findet ja bei allen 3 Methoden statt.

Und noch mal zu den Begriffen.... Unter Benutzer verstehe ich in der Informatik eine Entität, die durch ein Benutzerkonto in Realität gesetzt wird. Dann gibt es Dateien, an denen ein Benutzer "Besitz" haben kann. Dieser Besitz wird in den Metadaten einer Datei festgesetzt. Mit einer SID bzw. uid wird der Besitz an der Datei quasi "beurkundet", und genau diese "Besitz-Urkunde" wird gemappt. Somit wird der Benutzer dann persistent zum Besitzer der Datei. Parallel dazu gibt es dann noch Gruppen (in denen ein Benutzer Mitglied sein kann oder auch nicht) und den dazu passenden Guppen-Besitz, womit dann nicht nur Benutzer-Rechte, sondern auch noch Gruppen-Rechte realisiert werden. In Linux-Datei-Meta-Daten können nur dem User und der Group Rechte zugewiesen werden, die auch Besitzer der Datei sind und zusätzlich Others (=Jeder in Windows), Mit der ACL-Technik können auch anderen Benutzern Rechte eingeräumt werden, und sogar theoretisch den Besitzern keine.

Ein über das Administratoren-Root-Mapping hinausgehendes "Besitz-Urkunden-Mapping" für echte Benutzer (statt Phamtom-Benutzer) findet nur über die UserMapping-Datei statt. Die Rechte, die in den 2 Rechte-Mapping-Methoden UserMapping und permissions gemappt werden, sind immer die für einen User, eine Group und Others, egal ob die 3 mit den Entsprechungen im Windows-System gemappt sind. Erst ACL ermöglicht eine Rechtefestlegung über diese 3 hinaus für beliebig viele User und Groups.

Auch in Windows gibt es neben dem von newubunti erwähnten Besitz einen zusätzlichen "Gruppen-Besitz", welcher aber von dem üblichen Windows-Werkzeugen nicht angezeigt wird. Dieser wird aber noch relevant werden, wenn wir in die "Hölle" des "UserMapping" richtig einsteigen. Das für Links relevante "Volume-Mapping" ist Kindergarten dagegen.

Max-Ulrich_Farber schrieb:

@UlfZubis:

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!

Ich meine damit folgendes... Wenn ich mich z.B. mittels SSH auf einen anderen Rechner einlogge, dann melde ich mich dort ja an einem dort bestehenden Konto an. Ab dem Moment ist dieses Benutzer-Konto dann mit dem Benutzer-Konto auf meinen Rechner "gemappt". Obwohl ich als Benutzer des Clients arbeite, trete ich auf dem fremden Rechner als diesem nur bekannter Benutzer auf.

UlfZibis, können wir uns so einig werden? Dann hat uns ja Otto Waalkes wieder mal geholfen! 🤣

Ich glaube, wir sind dem erheblich näher gekommen ☺

Hallo,

ich bin normalerweise nicht derjenige der unbedingt Tabellen empfiehlt, aber im Fall vom Mapping hier finde ich die Tabelle mit den "File Creation Parameters" aus https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions#mount-options schon hilfreich:

Hinweis: Die Tabelle habe ich jetzt mal aus dem Link heraus versucht auf Ubuntu umzusetzen. Ich habe die Aussagen jetzt nicht vollständig überprüft. Eventuell kann hier noch verbessert korrigiert werden. Mir geht es nur um die Darstellungsart, um dem Leser letztlich aufzuzeigen, unter welchen Rahmenbedingungen was gilt.

LG, Newubunti

Bitte denkt einmal darüber nach, ob das ganze komplexe Thema "User Mapping" nicht aus diesem Artikel in einen separaten ausgelagert werden kann bzw. sollte. Mein Eindruck ist, dass sich dies positiv auf die Lesbarkeit auswirken könnte, da zahlreiche Fallunterscheidungen im Text vermieden werden.

Hintergrund: Es gibt drei Einsatzszenarien bei der Nutzung eines NTFS-Dateisystems unter Linux:

1. Man will Dateien aus dem NTFS-Dateisystem, vielleicht aus Windows, nur lesen oder kopieren. Dann benötigt man kein User-Mapping und sollte das Dateisystem mit Schreibschutz einbinden.

2. Man will in bereits vorhandene Dateien im NTFS-Dateisystem schreiben. Auch dann benötigt man kein User-Mapping.

3. Man will im NTFS-Dateisystem Dateien anlegen und diese von Windows aus benutzen. Dann sollte man User-Mapping konfigurieren.

Nur Leser/Anwender aus der dritten Klasse interessierten sich überhaupt für die Thematik User-Mapping, allen anderen sollte man den Komfort erlauben, das zu ignorieren und sie nicht ständig beim Lesen an etwas erinnern, was sie nicht benötigen.

Der Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Standard-Einstellungen“) könnte zugunsten der Tabelle entfallen in der war IMO übrigens ein Fehler. Es müsste IMO so aussehen:

Dadurch würde der Artikel IMO auch schon um einiges kürzer.

LG, Newubunti

@Newubunti.

Diese Tabelle kenne ich gut, ich habe sie ja auch immer zugrundegelegt. Allerdings erscheint mir die tabellarische Darstellung aller möglicher Kombinationen zu kompliziert und zu umfangreich. Eine "kausale" Analyse lässt alles viel einfacher erscheinen, und lässt sich auch viel kürzer fassen. In der Tabelle geht es ja um die Priorität der Optionen, falls mehrere einander widersprechende zusammen auftreten. Dabei gilt folgendes:

• Am besten vermeidet man es ganz, mehrere einander widersprechende Optionen in einer Befehlszeile zu verwenden. Dann ist alles sowieso klar.

• Wenn sich das nicht vermeiden lässt, dann gilt:

  • Ohne UserMapping-Datei: uid &Co, permissions, acl (Priorität absteigend)

  • Mit UserMapping-Datei: permissions, acl. Die Optionen uid & Co werden ignoriert. Falls keine Optionen oder nur uid & Co angegeben sind, gilt transparent acl.

Das ist der ganze Inhalt der komplizierten Tabelle. Mehr brauchen wir nicht.

@kB:

Die mühsame und endlos lange Diskussion zwischen UlfZibis und mir macht den Eindruck, dass es sich hier um ein wirklich sehr schwieriges, für viele unnötiges Thema handelt. Deshalb verstehe ich den Vorschlag von kB sehr gut, dieses hier auszuklammern.

Das ganze Problem war aber IMHO nicht in der Sache begründet, sondern in einem völlig verschiedenen Wortgebrauch. Was UlfZibis und ich unter "Mapping" verstehen, ist absolut nicht das gleiche! Und da ist es kein Wunder, dass wir einander nicht verstehen und das ganze dann wahnsinnig kompliziert erscheint. Und dazu kommt noch, dass Tuxera selbst den Begriff "schwammig" verwendet.

Ich halte mich genau an die (zweimal) zitierte Definition von "Mapping" in der Informatik. Diese wiederhole ich hier nicht nochmal. Für mich ist das "Mapping" hier nur die Übernahme bzw. Überführung von uid, gid, den drei Rechten r,w,x und, bei acl noch der POSIX-ACL, in einen SID. Das ist "Mapping" im strengen Sinn. Und genau das ist die Methode, mit der NTFS-3G persistente Rechte realisiert, falls eine der Optionen permissions oder acl vorliegt. Das gilt dort immer, so macht es NTFS-3G, und so macht es eben NTFS3 offenbar nicht. Es geht ja auch anders.

Nun nennt Tuxera diese Methode leider "User"-Mapping, womit Missverständnisse vorprogrammiert sind (und dann auch, wie man sieht, massiv auftreten). Denn beim sog. default user mapping ist ja überhaupt kein zweiter User oder ein anderes Betriebssystem oder sonst was im Spiel. Es ist nur das "Mapping" der Dateirechte im obigen Sinn, sonst gar nichts. Natürlich beziehen sich diese indirekt auch auf "Benutzer", aber die Bezeichnung suggeriert etwas anderes. Leider.

Natürlich könnte man sagen, "Lass einfach weg, wie NTFS-3G das macht. Dateirechte werden persistent, fertig". Dem könnte ich zustimmen, wenn es da nicht Fallen gäbe, in die man prompt hineintappt, wenn man nicht verstanden hat, wie NTFS-3G das macht. Die schlimmste davon ist, dass man alles durcheinander bringt, wenn man auf dem Weg, den man in NTFS3 benutzen muss (ich kenne jedenfalls keinen anderen) von Hand Linux- und Windows-Benutzer synchronisiert. Mit Sicherheit werden viele so vorgehen wollen (liegt ja nahe) und dann die Support-Anfragen und vielleicht sogar Fehlermeldugen damit füllen. Dieses lässt sich nur dadurch vermeiden (bzw. wenigstns vermindern), dass man die Unterschiede zwischen den Treibern erklärt. Und dazu gehört eben das "Mapping" der Benutzer- und Dateirechte auf einen SID speziell bei NTFS-3G.

Die UserMapping Datei macht nun nichts anderes, als dass sie NTFS-3G einen geeigneten SID anbietet um die Linux-Rechte darauf zu mappen, sodass sich damit automatisch eine Zuordnung zwischen Linux- und Windows-Benutzern ergibt. Wer will, kann diese Zuordnung vielleicht auch "Mapping" nennen, aber der Definition entspricht dieser Wortgebrauch nicht. Und, wie schon gesagt, die Verwendung des gleichen Begriffs in zweierlei Bedeutungen führt immer zu Verwirrung! Siehe hier…

Die ganze Geschichte mit der UserMapping-Datei ganz weglassen geht nicht. Sie irgendwo anders als in NTFS-3G abzuhandeln geht auch nicht. Aber sie (wesentlich) kürzer fassen geht vielleicht. Das will ich versuchen.

Mein Vorschlag: Im Übersichtsartikel die Synchronisation (bzw. Zuordnung) von Windows- und Linux-Benutzern thematisieren und Vor- und Nachteile der verschiedenen Wege darstellen. Wem der Weg über das Mapping bei NTFS-3G unnötig kompliziert erscheint, der kann ja NTFS3 wählen und die Zuordnung dort (aber eben ja nicht in NTFS-3G!) von Hand vornehmen. Er muss das dann halt bei jedem Ordner getrennt durchführen, aber zumindest bei Windows ist ihm ja die Vererbung behilflich, und in Linux gibt es auch den Parameter -R. Und wenn er Dateieigenschaften verändern will, muss er dies eben in beiden Betriebssystemen gleichermaßen tun. Im Heimbereich ist dies wohl zumutbar. Und NTFS-3G nimmt ihm halt all dies ab, indem es die Benutzer- und Zugriffsrechte von Linux schon auf einen geeigneten SID mappt - falls man ihm diesen mit einer UserMapping-Datei mitteilt.

kB, habe ich mich verständlich ausgedrückt? Ist wieder sehr lang geworden, tut mir Leid. ☹

L.G.

Max-Ulrich_Farber schrieb:

... Falls keine Optionen oder nur uid & Co angegeben sind, gilt transparent acl.

Was meinst Du denn damit?

Das ist der ganze Inhalt der komplizierten Tabelle. Mehr brauchen wir nicht.

👍

Für mich ist das "Mapping" hier nur die Übernahme bzw. Überführung von uid, gid, den drei Rechten r,w,x und, bei acl noch der POSIX-ACL, in einen SID.

Ich würde eher sagen: uid, gid werden in SIDs gemappt und Rechte, sowohl r,w,x als auch POSIX-ACL, in Windows-ACL.
Unklar ist mir dabei noch, wie bei permissions der Besitz gemappt wird, da auf Windows-Seite ja "Administratoren" als Besitzer eingetragen wird. Möglicherweise forstet NTFS-3G die ACL durch, findet darin Rechte bzgl. der Phamtom-User-SID und -Group-SID und nimmt die dann als Besitzer.

Nun nennt Tuxera diese Methode leider "User"-Mapping, womit Missverständnisse vorprogrammiert sind (und dann auch, wie man sieht, massiv auftreten). Denn beim sog. default user mapping ist ja überhaupt kein zweiter User oder ein anderes Betriebssystem oder sonst was im Spiel. Es ist nur das "Mapping" der Dateirechte im obigen Sinn, sonst gar nichts. Natürlich beziehen sich diese indirekt auch auf "Benutzer", aber die Bezeichnung suggeriert etwas anderes. Leider.

Sehr schön ausgedrückt, genauso meinte ich es.

... Und NTFS-3G nimmt ihm halt all dies ab, indem es die Benutzer- und Zugriffsrechte von Linux schon auf einen geeigneten SID mappt.

Deiner Definition nach müsste das doch eher eine "Zuordnung" sein, als ein "Mapping". Also Rechte werden uid/gid bzw. SIDs zugeordnet.

Ich würde eher sagen: uid, gid werden in SIDs gemappt und Rechte, sowohl r,w,x als auch POSIX-ACL, in Windows-ACL.

Das ist wahrscheinlich noch etwas präziser. Das Zusammenspiel zwischen SID und ACL in Windows habe ich nie richtig verstanden. Aber ein SID enthält schon mehr Informationen als nur UID bzw. GID. Aber ich bin froh, dass Windows letztlich nicht unser Thema ist.

Ich nehme an, dass das Mapping von r,w,x bzw. bei acl noch POSIX-ACL auf die Windows-ACL für alle Dateien immer nach dem gleichen Schema erfolgt. Deshalb ist das Mapping der User-UID bzw. Gruppen-GID auf jeweils einen SID interessanter.

... Und NTFS-3G nimmt ihm halt all dies ab, indem es die Benutzer- und Zugriffsrechte von Linux schon auf einen geeigneten SID mappt.

Deiner Definition nach müsste das doch eher eine "Zuordnung" sein, als ein "Mapping". Also Rechte werden uid/gid bzw. SIDs zugeordnet.

Ja, das war von mir ein bisschen schlampig ausgedrückt, das muss ich zugeben. Es müsste besser heißen:

... Und NTFS-3G nimmt ihm halt all dies ab, indem es die UID und GID, denen in Linux die Benutzer- und Zugriffsrechte zugeordnet sind, schon auf einen geeigneten SID mappt.

Also zuerst eine Zuordnung und dann ein Mapping. Du hast völlig Recht, Rechte sind noch keine Daten, erst durch die Zuordnung zu UID oder GID oder eben SID werden daraus Daten, die gemappt werden können.

Ich glaube, jetzt verstehen wir einander schon. Ich war eben so in meiner Definition für das Mappen von Daten verhaftet und festgefahren, dass ich einfach nicht verstehen konnte, was du mit "Phantom" oder "scheinbarer Benutzer" usw. gemeint hattest. Denn die UID, GID usw. und die SID bestehen doch alle "real", ob ein Windows-System die nun kennt oder nicht…

Auch wenn es mich manchmal aufgeregt hat, bin ich dir, UlfZibis, jetzt doch dankbar, dass du so hartnäckig dran geblieben bist und nicht einfach klein beigegeben hast. Denn nur so wurde ich heftig genug auf die Problematik des Begriffs "Mapping" aufmerksam gemacht, "mit der Nase darauf gestoßen". Danke! . Das ist ehrlich gemeint.

@Newubunti

Der Abschnitt Baustelle/Windows-Partitionen einbinden/NTFS-3G (Abschnitt „Standard-Einstellungen“) könnte zugunsten der Tabelle entfallen in der war IMO übrigens ein Fehler. Es müsste IMO so aussehen:

Ich glaube schon, dass dies möglich wäre, in der Tabelle steht sicher alles drin. Aber gefallen tut es mir nicht. Ich musste die Tabelle vielmals durchlesen, bis ich aus den vielen Einzelfällen die Struktur rekonstruiert hatte. Und nur diese konnte ich mir dann merken, die Vielzahl der Einzelfälle nicht. Aber ich will nicht vorschnell urteilen. Ich muss mir das noch durch den Kopf gehen lassen.

L.G.

EDIT:

Unklar ist mir dabei noch, wie bei permissions der Besitz gemappt wird, da auf Windows-Seite ja "Administratoren" als Besitzer eingetragen wird. Möglicherweise forstet NTFS-3G die ACL durch, findet darin Rechte bzgl. der Phamtom-User-SID und -Group-SID und nimmt die dann als Besitzer.

Das weiß ich auch nicht. Aber ich denke, das brauchen wir auch weder zu wissen noch zu schreiben. Wenn der Leser kapiert hat, wie es prinzipiell geht, dann kann er selber weiter forschen, wenn er will.

Welche Informationen in einem SID alle stecken, weiß ich nicht. Bei einem per default user mapping frei gewählten SID kann das nicht viel sein. Denn fast der ganze SID besteht da aus der Ziffernfolge der Kreiszahl Pi (3,1415926536…). Den Entwicklern ist wohl nichts anderes eingefallen, und warum auch nicht? Aber Informationen stecken da keine drin, außer negative. Nur die letzten paar Ziffern sind spezifisch für den jeweiligen UID bzw. GID.

UlfZibis schrieb:

Unklar ist mir dabei noch, wie bei permissions der Besitz gemappt wird, da auf Windows-Seite ja "Administratoren" als Besitzer eingetragen wird.

Administratoren wird von wo aus eingetragen?

Bei permissions wird doch der Ersteller der Datei im NTFS-Dateisystem als Besitzer der Datei eingetragen. Dabei gibt es zwei Möglichkeiten:

1. Mit UserMapping-Datei, dann wird die SID im NTFS-Dateisystem eingetragen, die der uid und gid des Erstellers in der UserMapping zugeordnet wurde.

2. Ohne UserMapping-Datei, dann wird eine von NTFS-3G generierte SID für die uid und gid des Erstellers im NTFS-Dateisystem eingetragen. Die Zuordnung bzw. Generierung der SID erfolgt nach meiner Beobachtung nach dem folgenden Schema:

   uid=1000 => SID=S-1-5-21-3141592653-589793238-462843383-12000
   gid=1000 => SID=S-1-5-21-3141592653-589793238-462843383-12001
   uid=1001 => SID=S-1-5-21-3141592653-589793238-462843383-12002
   gid=1001 => SID=S-1-5-21-3141592653-589793238-462843383-12003
   uid=1002 => SID=S-1-5-21-3141592653-589793238-462843383-12004
   gid=1002 => SID=S-1-5-21-3141592653-589793238-462843383-12005
   uid=1003 => SID=S-1-5-21-3141592653-589793238-462843383-12006
   gid=1003 => SID=S-1-5-21-3141592653-589793238-462843383-12007
   ...

Da das ein errechenbares Schema ist, kann bei erneutem Zugriff auch ohne UserMapping-Datei auf uid und gid zurückgerechnet werden.

LG, Newubunti

Newubunti schrieb:

[…] Da das ein errechenbares Schema ist

Nein, das ist nicht berechenbar, sondern in Deinem Fall (hoffentlich weltweit) einmalig so.

Siehe : https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/understand-security-identifiers

kann bei erneutem Zugriff auch ohne UserMapping-Datei auf uid und gid zurückgerechnet werden.

Da der Teil 21-… die willkürlich gewählte Domänenbezeichnung und der letzte Teil den ebenso willkürlich gewählten lokalen Bezeichner darstellt, sehe ich für eine zuverlässige Rückrechnung keine Chance. Selbst wenn man annimmt, dass die Vergabe der lokalen Bezeichner aufsteigend erfolgt, hängt der Wert von der Reihenfolge ab, mit der die relevanten uid zur Kenntnis genommen werden. Aus dem numerischen Wert eines lokalen Bezeichners unter Windows kann man m.E. nicht auf den numerischen Wert eines uid unter Linux schließen und umgekehrt ebenso nicht.