Mit der Methode erreicht man, dass Linux-seitig erzeugte Dateien mit NTFS-Vollzugriff für jedermann abgelegt werden. Damit wird allerdings der Schutz durch die Windows-Benutzerrechte ausgehebelt.
Ich verstehe nicht, was dies mit dem statischen Festlegung von umask, UID und GID beim Einbinden von NTFS-Partitionen versus permissions,acl zu tun hat. Dies ist doch unabhängig von der "Methode" immer der Fall, wenn kein User-Mapping festgelegt ist.
acl erfordert, dass man auch Linux-seitig ACLs verwendet statt der klassischen Zugriffsrechte
nicht "erfordert", sondern "erlaubt"…
Mit permissions werden Linux-seitig erzeugte Dateien unter NTFS-Eigentümer-SIDs abgelegt, die Windows nicht kennt.
und damit hat dann von Windows aus wieder jedermann Zugriff (s.o.) Ohne User-Mapping merken also Windows-Benutzer gar nichts davon, ob Linux-seitig die Option permissions besteht oder nicht.
Allgemein gilt doch: Wenn kein User-Mapping stattfindet, dann haben immer alle Benutzer im jeweils anderen Betriebssystem prinzipiell Vollzugriff, in Linux jedoch noch abhängig von den Mount-Optionen umask,uid,gid.
Leider wurde da auch nicht alles berücksichtigt, mein vorgeschlagener Ausweg aus dem Dilemma wurde bisher nicht umgesetzt.
Ich habe den betreffenden Thread kurz überflogen. Es ist klar, dass eine umkehrbar eindeutige Übertragung der Linux-Gruppenstruktur auf Windows-Gruppen oft nicht möglich ist.
It is a strong assumption in ntfs-3g that users are organized the same way in Windows and Linux. Otherwise you cannot grant or deny access according to group membership.
Spezielle, zudem nicht gerade einfache Workarounds für Windows-Versionen vor Win-8, sind sicher nicht mehr lohnend. – Doch dies sind reine Probleme des User-Mapping und haben mit den verwendeten Mount-Optionen ("Methode") direkt nichts zu tun.
Ich sehe hier also kein Problem der Optionen permissions,acl.
