ubuntuusers.de

Muss man den Gruppen-Eintrag überhaupt setzen? Ich weiß in Windows nicht Bescheid, aber in der UserMapping-Datei müssen AFAIK alle Zeilen die Form haben:

1000:1000:S-1-5-21-100139866-1955529089-4104550190-1001

wobei die Einträge für UID und GID auch leer sein dürfen, aber der SID muss wohl der Form entsprechen (??). Und – wie bei fstab – mit LF abschließen!

Also ich hatte aufgrund des Abschnittes ACL geschlossen, dass eine Zuweisung

:100:S-1-5-32-545

möglich wäre. S-1-5-32-545 ist die Gruppe Benutzer (Users) unter Windows. Das geht aber offenbar nicht.

Was bei mir funktioniert ist, die Zuweisung zu einer unter Windows explizit angelegten Gruppe, also das hier

:100:S-1-5-21-100139866-1955529089-4104550190-1004

funktioniert.

Was aber nach wie vor nicht wie im Handbuch und im Wiki beschrieben ist, dass er ohne Option acl und ohne Option permissions und mit vorhandener .NTFS-3G/UserMapping automatisch acl wählt. Das scheint mir eher permissions zu sein.

Es wäre gut, wenn das noch ein anderer überprüfen würde.

LG, Newubunti

Es wäre gut, wenn das noch ein anderer überprüfen würde.

Ja, zweifellos! Nur fehlen mir leider die nötigen Kenntnisse der Rechteverwaltung in Windows,um das systematisch überprüfen zu können. Und da kann (und will) ich mich jetzt so schnell nicht einarbeiten. Deshalb habe ich eben mehr oder weniger ungeprüft das übernommen, was in der Anleitung des Herstellers steht. Es handelt sich ja nicht um eine Dissertation. Plagiate sind ja offenbar hier wie dort üblich, doch im Wiki sogar (in diesem Fall) erlaubt!

Interessant wäre jetzt, ob sich bei deinen Versuchen mit einer UserMapping-Datei irgend etwas ändert, wenn du die Option acl von Hand einträgst. Nach den Angaben des Herstellers müsste das völlig egal sein und gar nichts ändern. Es müsste hingegen u.U. bedeutsam sein, ob man die Option permissions einträgt oder nicht.

Ich weiß nicht, wie sich acl verhält, wenn sich die Windows-Rechte ohne Zuhilfenahme von POSIX-ACL allein mit UNIX-Dateirechten darstellen lassen. In umgekehrter Richtung ist das klar: Sowohl UNIX-Dateirechte als auch, falls vorhanden, POSIX-ACL werden auf Windows-ACL gemappt. Und wenn dabei "Pseudo"-Windows-ACL entstehen, mit denen Windows nicht klar kommt, dann hat man eben Pech gehabt.

"Sondrrechte" via POSIX-ACL können aber nur für User und Gruppen berücksichtigt werden, die auf SID gemappt sind. Deshalb bleiben wohl bei Fake-Usermapping-Dateien ohne Eintrag für UID und GID die Optionen acl und permissions gleichbedeutend. So habe ich dies wenigstens verstanden (?). Aber richtig klar ist mir das nicht: Für die nicht gemappten UID und GID könnten doch SID im "PI-Bereich" (so von mir genannt wegen der Ziffernfolge) angelegt werden und damit dann Linux-intern POSIX-ACL gemappt werden, wie das im default user mapping ja wohl geschieht (?).

Deshalb sind mir die beiden Hersteller-Angaben, dass einerseits eine UserMapping-Datei die Option acl auslöst und andererseits eine Fake-Usermapping-Datei gleichbedeutend ist mit default user mapping mit der Option permissions nur oberflächlich gesehen wirklich plausibel. Das ganze scheint mir, um mit kBzu sprechen, eine "Hölle" zu sein!

L.G.

Max-Ulrich_Farber schrieb:

Es wäre gut, wenn das noch ein anderer überprüfen würde.

Ja, zweifellos! Nur fehlen mir leider die nötigen Kenntnisse der Rechteverwaltung in Windows,um das systematisch überprüfen zu können. Und da kann (und will) ich mich jetzt so schnell nicht einarbeiten. Deshalb habe ich eben mehr oder weniger ungeprüft das übernommen, was in der Anleitung des Herstellers steht. Es handelt sich ja nicht um eine Dissertation. Plagiate sind ja offenbar hier wie dort üblich, doch im Wiki sogar (in diesem Fall) erlaubt!

Du brauchst doch für die Überprüfung gar kein Windows. Mir geht es nur darum, ob bei Vorhandensein einer .NTFS-3G/UserMapping ohne weitere Mountangaben, acl oder permissions oder sonst was gilt.

Dafür musst Du nur

1. eine .NTFS-3G/UserMapping anlegen,

2. ohne Angabe einer Mount-Option mit ntfs-3g einbinden,

3. eine Datei und einen Ordner anlegen,

4. chown, chgrp und chmod versuchen,

5. auf der Datei und dem Ordner ACL mit setfacl setzen (versuchen),

6. die Partition aushängen,

7. die Partition erneut wie unter 2. einhängen und gucken, ob die gegebenenfalls gesetzten Rechte noch bestehen.

Natürlich schreiben wir hier keine Dissertation. Allerdings gibt es im Wiki auch nicht die Pflicht, auf jede Option einzeln einzugehen. Wenn sich nun andeuten sollte, dass sich acl nicht so wie im Hanbuch beschrieben verhält, dann kann man

1. es so darstellen wie es "korrekt" ist bzw. wie es sich unter Ubuntu darstellt,

2. es ganz aussparen,

3. es exakt 1:1 nach Handbuch übersetzen und darauf hinweisen, dass es sich in dem Fall nur über eine Übersetzung aus dem Handbuch handelt,

4. es weiterhin "falsch" darstellen .

Ich wäre dann für 1. oder 2., aber nicht für 4. - eventuell kann ich mich auch noch mit 3. anfreunden.

LG, Newubunti

Das ist natürlich kein Problem, das kann ich gerne ’mal machen. Ich dachte an die Überprüfung ob die POSIX- ACL korrekt in Windows-ACL übernommen werden und umgekehrt. Da hätte ich schon Probleme.

Ich bin im Moment sehr erkältet, mache das aber, wenn ich wieder besser "aus den Augen schauen" kann.

L.G.

Max-Ulrich_Farber schrieb:

... Ich bin im Moment sehr erkältet, mache das aber, wenn ich wieder besser "aus den Augen schauen" kann.

Gute Besserung und mache Dir kein Stress damit!

LG, Newubunti

Es ist bei mir auch so, wie Newubunti schrieb:

Ich habe eine Partition mit Datei .NTFS-3G/UserMapping ohne explizit angegebene Mount-Optionen mittels GUI eingehängt (d.h. gleichbedeutend mit gio mount -d). Ich kann darauf mit setfacl… keine ACL einrichten. Die Befehle chmd und chown funktionieren aber.

Mit einer Fake-UserMapping-Datei ohne UID und GID funktioniert es genau so.

Wenn ich nun die gleiche Partition mit explizit angegebener Option acl einbinde, dann funktioniert setfacl jedoch einwandfrei.

(Xubuntu 22.04, Kernel 6.5)

L.G.

EDIT

Es geht noch weiter: Wenn beide Optionen permissions und acl explizit angegeben sind, dann gilt acl und nicht permissions … Dies bedeutet: Die Priorität der Optionen wurde (irgendwann…) stillschweigend umgekehrt (wenn man nicht annimmt, dass die Anleitung von Anfang an falsch war…).

Da es sich um eine FUSE-Anwendung handelt, ist die Kernel-Version wohl irrelevant, es spielt nur die Version von NTFS-3G eine Rolle. (ntfs-3g 2021.8.22 integrated FUSE 28)

Beim standardmäßig grafischen Einhängen wird allerdings mittels udisks immer uid=$UID und gid=$GID verwendet.

Allerdings auch wenn ich

sudo mount -t ntfs-3g /dev/vdb1 /media/ntfs 

benutze, habe ich permissions als das dann geltende "Standardverhalten". Ich habe auch schon überlegt, ob das Handbuch vielleicht gar nicht falsch liegt, aber bei Verwendung von FUSE eben doch immer irgendwie uid= und gid= verwendet werden. Das ist aber auch nicht so wichtig, ins Wiki kann man dann einfach einen Satz schreiben wie:

Möchte man POSIX (Draft) ACL verwenden, dann muss man die Option acl unter Ubuntu - abweichend zu man ntfs-3g - explizit angeben. Soll dies auch für das grafische Einbinden mittels z.B. Dateimanager gelten, so kann man das ab Ubuntu 22.04 über udisks konfigurieren.

Noch eine Frage:

Ist es bei Dir auch so, dass wenn ACL mittels Option acl verwendet werden, dass dann chown, chgrp und chmod nicht funktionieren?

Weil falls ja, dann wäre das auch noch eine Erwähnung im Unterschied zu permissions und auch im Unterschied zur sonstigen Nutzung von ACL auf z.B. ext4 wert.

LG, Newubunti

Beim standardmäßig grafischen Einhängen wird allerdings mittels udisks immer uid=$UID und gid=$GID verwendet.

So ist es bei mir auf der Maschine mit Kernel 6.5. Auf der anderen mit Kernel 5.15 ist es aber root:root. Sicher ist die andere Version von udisks schuldig. Mit der fake-UserMapping-Datei ist es aber für alle Dateien, die noch keine persistenten Rechte haben (also z.B. Windows-Dateien oder solche von NTFS3) bei beiden root:root. Das sieht tatsächlich danach aus, dass von udisks per default $USER:$USER gesetzt wird, was durch die UserMapping-Datei wieder ausgehebelt wird.

Ist es bei Dir auch so, dass wenn ACL mittels Option acl verwendet werden, dass dann chown, chgrp und chmod nicht funktionieren?

Ich sehe schon, ich muss den ganzen Bereich nochmal durchtesten. Ich habe mich da offenbar allzu blauäugig auf das Handbuch verlassen.

Die Befehle chown und chmod funktionieren mit Einschränkungen (keine Schreibrechte möglich für Gruppe $USER; wahrscheinlich weil $USER:$USER nur eine SID haben ?). Doch alles funktioniert anscheinend wie bei ext4 wenn beide Optionen permissions und acl gesetzt sind.

Bisher habe ich nur innerhalb von Linux experimentiert und Windows ganz außen vor gelassen.Interessant wäre auch, wie es mit den Optionen beim "Rückweg" Windows nach Linux aussieht.

Nochmal $USER:$USER: Es ist tatsächlich so wie vermutet: in http://storaged.org/doc/udisks2-api/latest/mount_options.html findet man:

ntfs:ntfs_defaults=uid=$UID,gid=$GID,windows_names

wzbw.
und bei ntfs:ntfs3_defaults fehlen dann die windows_names (alles Kernel 6.5).

L.G.

Also nach meiner Beobachtung verhält es sich mit nur der Option acl bei vorhandener .NTFS-3G\UserMapping wie folgt:

• Existiert in .NTFS-3G/UserMapping eine Mapping für einen Benutzer und eine Gruppe - damit meine ich eine explizite Gruppe, wie ntfsusers und nicht die Primär-Gruppe eines Linux-Benutzers - dann funktionieren chown und chgrp, wie sonst von Linux gewohnt.

• Fehlt dagegen ein Mapping für einen Benutzer oder eine Gruppe die bei chonw und chgrp übergeben werden sollen, dann führen chown oder chgrp immer zu root:root.

Das entspricht dann wohl

If no mapping is defined for some user or group, root rights are used, giving access to all files. Similarly, if no mapping is defined for the owner (or group) of some file, it appears as owned by root, and depending on protections, it may be accessible to root only.

aus dem NTFS-3G-Wiki.

Es wäre IMO wohl geschickter, wenn man die Optionen permissions und acl getrennt erklärt.

LG, Newubunti

Das verwirrt mich jetzt noch mehr. Denn meine Beobachtungen von gestern sind anscheinend nicht reproduzierbar:

Die Befehle chown und chmod funktionieren mit Einschränkungen (keine Schreibrechte möglich für Gruppe $USER; wahrscheinlich weil $USER:$USER nur eine SID haben ?). Doch alles funktioniert anscheinend wie bei ext4 wenn beide Optionen permissions und acl gesetzt sind.

Ich habe nochmal versucht, den Vorgang von gestern nachzuvollziehen. Es gab keinen Unterschied mehr zwischen acl allein und acl,permissions.

Eine mögliche Erklärung (??) für das andersartige Verhalten gestern ist, dass vielleicht die Partition vor dem Mounten nicht korrekt ausgehängt war. Dies kann sein, wenn noch ein Terminal offen war, und ich mit "trotzdem aushängen" ausgehängt hatte. Das mache ich jedenfalls jetzt nicht mehr!! Faulheit gehört bestraft…

Meine heutigen Beobachtungen stimmen mit denen von Newubunti überein. Die Optionen chown und chmod funktionieren, wenn User und Gruppe in der UserMapping-Datei vorhanden sind, sonst geht alles an root:root – wie im Manual steht. Und das gilt gleichermaßen für permissions und acl.

Seltsam: Wenn ich mit acl bzw. permissions,acl einbinde, bekommen alle Ordner und Dateien der Partition bei ls -l das + für ACL, auch wenn gar keine gesetzt wurden (wieso?). Mit permissions ohne acl fehlt dieses natürlich. Sonst ist das Verhalten bei chown und chmod aber gleich. Auf einer ext4-Partition fehlt dieses automatische + , obwohl dort ja ACL genau so möglich sind. Mit getfacl merke ich keinen Unterschied zu einer ext4-Partition, wenn acl gesetzt ist. Das automatische + hat anscheinend keinerlei Auswirkungen (??).

Es wäre IMO wohl geschickter, wenn man die Optionen permissions und acl getrennt erklärt.

Aber das alles mit chown und chmod usw. ist doch für beide Optionen genau gleich, oder nicht?

L.G.

EDIT:

Das automatische + hat anscheinend keinerlei Auswirkungen (??).

Es könnte vielleicht Auswirkungen haben, wenn man die Datei z.B. mittels Samba freigibt. Aber das will ich jetzt keinesfalls untersuchen. Sonst kommen wir ja nie zu einem Ende!

Max-Ulrich_Farber schrieb:

Das verwirrt mich jetzt noch mehr. Denn meine Beobachtungen von gestern sind anscheinend nicht reproduzierbar:

Diesen Eindruck hatte ich die Woche beim Testen der acl-Option auch schon mehrfach. Da hatte ich sie aber auch noch nicht richtig verstanden und hatte ja auch Anfangs ein Problem mit der Mapping-Datei.

Jetzt wo ich - glaube 😀 - verstanden zu haben wie es sein sollte, werde ich das noch mal systematisch testen.

Seltsam: Wenn ich mit acl bzw. permissions,acl einbinde, bekommen alle Ordner und Dateien der Partition bei ls -l das + für ACL, auch wenn gar keine gesetzt wurden (wieso?).

Das ist jedenfalls bei mir genauso. Warum das so ist, habe ich mir keine Gedanken drüber gemacht und ich gehe der Sache auch nicht auf den Grund. Vielleicht im Artikel einfach kurz erwähnen, damit man weiß, dass das so normal ist.

Im Grunde finde ich das ganz hilfreich, weil man so immerhin sieht, dass die Option acl greift.

Es wäre IMO wohl geschickter, wenn man die Optionen permissions und acl getrennt erklärt.

Aber das alles mit chown und chmod usw. ist doch für beide Optionen genau gleich, oder nicht?

Diese Aussage von mir könnte etwas damit zu tun habe, dass hinsichtlich der Option acl der Groschen heute erst richtig bei mir gefallen ist.

Von der Logik müsste es gleich sein, bis auf eben den Umstand, dass man mit acl eben über ACE/ACL zusätzliche Berechtigte definieren kann.

Ich melde mich dazu noch mal.

LG, Newubunti

Wenn ich es richtig verstanden habe (?), dann ist es so:

• acl ist ein Zusatz zur Option permissions und umfasst diese (d.h. acl allein ist identisch mit permissions,acl).

• eine UserMapping-Datei löst, wenn keine Option angegeben ist, permissions aus. Wenn man acl haben will, muss man dies explizit angeben.

Ich bin bis jetzt ausschließlich in Linux geblieben. Ob diese Aussagen auch für die Interpretation von Windows-Dateirechten unter Linux gelten, kann ich nicht sagen. Mit dieser Frage fühle ich mich im Moment leider etwas überfordert. Es könnte z.B. sein, dass die Windows-ACL bei acl ohne Umwege in POSIX-ACL übertragen werden, während mit permissions,acl zuerst versucht wird, dies mittels UNIX-Dateirechten zu lösen, und dass die ACL dann nur ggf. ergänzende Funktion haben. Aber das ist nur eine Idee, überprüft habe ich da noch gar nichts.

Ich habe leider kein Mehrbenutzer-Dual-Boot System zur Verfügung. Ich müsste mir erst eines basteln, und das macht – mit meinen geringen Windows-Kenntnissen – Mühe. Ich habe deshalb mit meinen bisherigen Beobachtungen eine Support-Anfrage an Tuxera gesandt. Entweder, die sagen mir, dass ich alles nicht richtig verstanden habe, oder sie erklären, ob und warum es so ist.

Jetzt wo ich - glaube 😀 - verstanden zu haben wie es sein sollte

Ich habe dies wohl immer noch nicht richtig verstanden. Denn folgende zwei Sätze in man ntfs-3g widersprechen sich IMHO:

1. acl: … It is set by default when a user mapping file is present and the permissions mount option is not set.

2. permissions: … This option is set by default when a user mapping file is present.

2. ist wohl richtig und 1. ist IMHO falsch (bzw. missverständlich?)

Bitte bei den Beispielen auf die Pseudo-Option defaults für mount verzichten.

Die Pseudo-Option defaults ist lediglich eine Abkürzung für rw,suid,dev,exec,auto,nouser,async. Das sind keineswegs allgemeingültige Standard-Vorgaben (welche man gemäß des Namens erwarten könnte) und nicht einmal generell zu empfehlende Vorgaben. Empfehlenswert sind dagegen nodev und mindestens nosuid oder besser noexec. Bei UDisks ist z.B. nodev,nosuid eingebauter Standard. Weiter will man auto/noauto in der Regel selbst in der Datei fstab kontrollieren und nouser gehört zu den bei ntfs-3g heiklen Optionen. defaults in seiner vollen Bedeutung ist eigentlich nur beim Root-Dateisystem eines Linux-Systems sinnvoll.

Für NTFS generell sind aus meiner Sicht statt defaults sinnvoller:

• noauto,nodev,nosuid (noauto weglassen, wenn man auto haben möchte) und alles andere auf den wirklichen Voreinstellungen belassen (insbesondere relatime), diese allgemeinen Optionen ergänzen mit den sinnvollen spezifischen Optionen für ntfs-3g wie z.B. windows_names.

• nosuid würde ich gerne verschärfen auf noexec, das verbietet aber einige Anwendungsfälle.

Max-Ulrich_Farber schrieb:

Wenn ich es richtig verstanden habe (?) […]

Ich verstehe es aus dem NTFS-3g-Wiki so:

1. Es gibt ein Verfahren UserMapping, welches die Rollen auf beiden Zeiten einander zuordnet.

2. Dieses Verfahren kann aktiv sein oder auch nicht.

3. Wenn es nicht aktiv ist,

   • dann arbeitet man mit den temporär simulierten Dateibesitzern, -gruppen und -rechten und kann dies über die Optionen uid, gid, umask, dmask, fmask steuern,

   • anderenfalls (also Verfahren UserMapping ist aktiv) sind die Optionen uid, gid, umask, dmask, fmask wirkungslos.

4. Man schaltet das Verfahren UserMapping ein, indem man eine (nicht leere?) Zuordnungsdatei .NTFS-3G/UserMapping anlegt oder die Mount-Option permissions angibt. Anstatt der Standarddatei kann man auch über die Mount-Option usermapping= eine andere Datei angeben.

5. Wenn das Verfahren UserMapping aktiv ist, dann gelten die Zuordnungen aus der o.g. Zuordnungsdatei oder wenn diese nicht existiert (oder leer ist?) eine Standard-Zuordnung als Vorgabe (das default user mapping). Diese Standard-Zuordnung lautet:

   ::S-1-5-21-3141592653-589793238-462643383-10000 

   und führt dazu, dass

   • auf der Linux-Seite angelegte Dateien unter Windows einem fremden Benutzer gehören,

   • und auf der Windows-Seite angelegte Dateien unter Linux root gehören.

6. Wenn das Verfahren UserMapping aktiv ist, kann man noch eins daraufsetzen und zusätzlich per Mount-Option acl auf der Linux-Seite die POSIX-ACLs aktivieren.

7. Wenn man die POSIX-ACLs aktiviert, wird dadurch implizit das Verfahren UserMapping aktiviert, sofern es noch nicht aktiv ist.

In Kürze:

• Zuordnungsdatei vorhanden oder eine der Mount-Optionen usermapping=, permissions, acl angegeben → Verfahren UserMapping ist aktiv.

• Vorstehende Bedingungen alle nicht erfüllt → Verfahren „Temporär simulierte Dateirechte“ ist aktiv.

• Verfahren UserMapping ist aktiv. → POSiX-ACLs optional zusätzlich möglich.