Zfs: NFS/POSIX ACL-Unterstützung

Erstellt am 23. März 2011  ·  51Kommentare  ·  Quelle: openzfs/zfs

Es ist gut, POSIX ACL-Unterstützung zu haben.
Wie ich sehe, haben zfs bereits xattr-Unterstützung und einige andere Dateisysteme haben ACL-Unterstützung über xattr gemacht. Ich kenne die Interna nicht, aber diese Aufgabe kann einfach zu implementieren sein.

Feature

Hilfreichster Kommentar

Posix-ACLs im Linux-Stil wurden als xattr implementiert und in Master eingebunden. Sie werden unabhängig von den nativen NFS-ACLs gespeichert und führen nicht zu Konflikten. Die neue Dataset-Eigenschaft acltype wurde hinzugefügt, um diese Funktionalität zu ermöglichen. Für die beste Leistung wird dringend empfohlen , sowohl xattr=sa zu setzen . Weitere Details finden Sie auf der aktualisierten Manpage:

       acltype=noacl | posixacl

           Controls  whether  ACLs  are  enabled and if so what type of ACL to
           use.  When a file system has the acltype property set to noacl (the
           default)  then  ACLs are disabled.  Setting the acltype property to
           posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
           cific  to  Linux  and are not functional on other platforms.  Posix
           ACLs are stored as an xattr and therefore will  not  overwrite  any
           existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
           are supported on Linux.

           To obtain the best performance  when  setting  posixacl  users  are
           strongly encouraged to set the xattr=sa property.  This will result
           in the Posix ACL being stored more efficiently on disk.  But  as  a
           consequence of this all new xattrs will only be accessable from ZFS
           implementations which support the xattr=sa property.  See the xattr
           property for more details.

Alle 51 Kommentare

Die Dinge sind leider etwas kniffliger, als es zunächst den Anschein hat.

Intern unterstützt und erzwingt ZFS ACLs im NFS-Stil. Leider manipulieren die vorhandenen Tools unter Linux nur ACLs im Posix-Stil. Es wurde einige Arbeit geleistet, um das NFS-ACL-Modell unter dem Namen Rich-ACLs auf Linux zu bringen. Zur Integration in die neue Rich-ACL-Toolkette muss ZFS eine virtuelle system.richacl-xattr-Schnittstelle bereitstellen. Dieses xattr würde nicht wie andere xattr gespeichert, sondern würde stattdessen in zfs_getacl() und zfs_setacl() integriert. Dieser xattr-Hook wäre für die Übersetzung eines vsecattr_t in und aus einem linearen Bytestrom für den xattr verantwortlich.

Posix-ACLs können einfach unterstützt werden, indem einige Hooks hinzugefügt und die vorhandenen Posix-ACL-Unterstützungsfunktionen genutzt werden. Es kann jedoch am besten sein, sie nicht zu implementieren, um Kohärenzprobleme zwischen Posix und Rich ACLs (NFS/ZFS) zu vermeiden.

Vielen Dank für die Beschreibung. Ich denke, POSIX ACL kann auch hilfreich sein, wenn es einige Anwendungen gibt, die POSIX ACLs unterstützen. Soweit ich mich erinnere, hat Samba so etwas. rsync hat ACL-Unterstützung, aber ich bin mir nicht sicher, ob es nur POSIX gibt, weil man nur "ACL" sagt. Kenne keine anderen Anwendungen.
Ich möchte nur sagen, dass sie auch mit anderen ACLs nicht nutzlos sind. Und kann als zukünftig implementiert angesehen werden.

Zusammenfassung der erforderlichen Arbeiten

Intern unterstützt und erzwingt ZFS ACLs im NFS-Stil. Leider manipulieren die vorhandenen Tools unter Linux nur ACLs im Posix-Stil. Es wurde einige Arbeit geleistet, um das NFS-ACL-Modell unter dem Namen Rich-ACLs (pdf) auf Linux zu bringen. Zur Integration in die neue Rich-ACL-Toolkette muss ZFS eine virtuelle system.richacl-xattr-Schnittstelle bereitstellen. Dieses xattr würde nicht wie andere xattr gespeichert, sondern würde stattdessen in zfs_getacl() und zfs_setacl() integriert. Dieser xattr-Hook wäre für die Übersetzung eines vsecattr_t in und aus einem linearen Bytestrom für den xattr verantwortlich.

Posix-ACLs können einfach unterstützt werden, indem einige Hooks hinzugefügt und die vorhandenen Posix-ACL-Unterstützungsfunktionen genutzt werden. Es kann jedoch am besten sein, sie nicht zu implementieren, um Kohärenzprobleme zwischen Posix und Rich ACLs (NFS/ZFS) zu vermeiden.

Was ist mit einer Einhängeoption / Dateisystemeigenschaft, WELCHES Sicherheitsmodell muss durchgesetzt werden? (und vielleicht der andere, der sogar vor Verwaltungstools wie setfacl/getfacl vollständig verborgen ist).
In der Linux-Welt sind Rich-ACLs fast ungenutzt. Posix-ACLs werden viel häufiger verwendet. In meinen typischen Konfigurationen ist das Fehlen von ACLs für ein Dateisystem ein Showstopper.
Ich denke, dass wir auf diese Weise in viel kürzerer Zeit eine funktionierende ACL-Implementierung (Posix) erhalten können.

Auch ich würde mir wünschen, dass die POSIX ACL-Unterstützung in ZFS unter Linux integriert ist. Linux ist POSIX, und bis RichACLs mehr Mainstream sind (oder zumindest im Kernel), denke ich, dass die POSIX-Integration in ZFS unter Linux sinnvoll ist.

Das würde ich gerne inklusive sehen! War fast ein Showstopper für uns, entschied sich aber, für ein paar Monate ohne zu leben.

Wenn ACLs sauber gehandhabt werden, sollten wir sicherstellen, dass der folgende Patch zur Wiederverwendung der aclmode-Eigenschaft zusammengeführt wird. Diese Änderung wurde bereits an den Illumos- und FreeBSD-Implementierungen vorgenommen.

Problem #742: Beleben Sie die ZFS-Eigenschaft "aclmode" wieder
https://www.illumos.org/issues/742
https://github.com/illumos/illumos-gate/commit/a3c49ce110f325a563c245bedc4d533adddb7211

Es ist möglich Posix < - > NFSv4 ACLs zuzuordnen.
Die IETF hat einen Entwurf zu dieser Zuordnung: http://tools.ietf.org/id/draft-ietf-nfsv4-acl-mapping-03.txt
Aber es gibt nur eindeutig Posix => NFSv4 (unidirektional) an.

Ich denke, dass der Mapping-Ansatz theoretisch der beste ist, aber er ist fehleranfälliger als andere, da ein 1:1-Mapping nicht möglich ist.
Es wird immer Eckfälle geben, in denen einem Benutzer ein Privileg verweigert (oder schlimmer, gewährt) wird, das nicht verweigert (oder schlimmer, gewährt) werden soll.
Zumindest sollte es mit einer "großen, fetten Warnung" kommen.
Aber es ist nicht ratsam, eine _Sicherheitsfunktion_ zu haben, die _muss_ sich annähern, was sie tun soll.
Vorschlag: bei "zweideutigem" NFSv4 acl verbieten Sie JEDEN Zugriff und drucken Fehler im Kernel-Log.
Problem bei diesem Vorschlag: Snapshots können nicht manuell korrigiert werden.
Sie zu setzen sollte kein Problem sein, da es einfach als ein „seltsames“ On-Disk-Format für Posix ACLs angesehen werden kann.
Die viel besser konfigurierbare Vererbung von NFSv4-ACLs führt zu einer weiteren Reihe von Problemen, die gelöst werden müssen.

Ich denke, dass diese Implementierung in einem ersten Schritt in der Lage sein sollte:

  • Schreiben Sie POSIX-ACLs, lesen Sie das Geschriebene und setzen Sie es durch.
  • schreiben Sie sie als NFSv4-ACL auf die Festplatte, damit andere Implementierungen sie auch wie beabsichtigt lesen und erzwingen können.
  • FAIL LOUDLY mit nicht trivial zuordenbaren NFSv4-ACLs, die von anderen Implementierungen geschrieben wurden.
    ** JEGLICHEN Zugriff auf diese Elemente verweigern.
    ** Benutzer dürfen keine Dateien in Verzeichnissen mit "besonderen" Vererbungsflags erstellen
    ** möglicherweise "Fehlerverhalten", das auf Dateisystembasis mit dem sichersten Standardwert konfigurierbar ist. (und für Schnappschüsse??)

In aufeinanderfolgenden Schritten kann die Mapping-Logik NFSv4 => Posix abgestimmt und viel individueller gestaltet werden.

Irgendwelche besseren Ideen?

Dies scheint mir ein vernünftiger Ausgangspunkt zu sein, nur ein paar Kommentare.

Während ein perfektes 1:1-Mapping nicht möglich ist, sind die Dinge eigentlich nicht so schlimm. Wie Sie darauf hinweisen, gibt es eine gut spezifizierte IETF Posix -> NFSv4-Zuordnung, die verwendet werden kann, um die richtigen ACLs auf der Festplatte einzustellen. Sobald die vorhandene ZFS-Implementierung auf der Festplatte als SA festgelegt wurde, sollte sie unabhängig von generischen Linux-ACL-Hooks im VFS erzwungen werden.

Sie müssen dann natürlich ein vernünftiges NFSv4 -> Posix-Mapping implementieren, um die ACLs zu lesen. Es gibt jedoch bereits sinnvolle Implementierungen davon. Ein Beispiel dafür ist der Linux-nfs-Kernelserver, der gezwungen ist, alle seine NFSv4-ACLs als Posix-ACLs zu speichern, was eine verlustbehaftete Operation ist. Abgesehen davon wäre es auf längere Sicht eine gute Sache für den nfs-Kernel-Server, die rohe nfsv4/zfs-ACL offenzulegen. Sie könnten möglicherweise eine sinnlose NFSv4 -> Posix -> NFSv4-Konvertierung vermeiden.

Schließlich möchten wir eine Testsuite haben, um zu überprüfen, ob wir das richtig gemacht haben. Dies ist schließlich ein Sicherheitsmerkmal. Zum Glück gibt es nach meinem Verständnis bereits mehrere gute Testsuiten.

Es gibt eine Arbeit über die Richacls von Aneesh kumar, Andreas Grünbacher über die vorherige Arbeit von Greg Banks. Es wurden Patches für 3.1 mainline merged. eingereicht, aber aufgrund einiger Änderungen wird es einige Zeit dauern und in der nächsten Version zusammengeführt werden.
Link zu Patches: - https://lkml.org/lkml/2011/10/18/279

Sobald dies zur Hauptlinie gelangt, können wir sie verwenden, um nfsv4acls für ZFS zu unterstützen.

Sobald dies zur Hauptlinie gelangt, können wir sie verwenden, um nfsv4acls für ZFS zu unterstützen.

Und was ist mit POSIX-ACLs? Brian sagte, dass es nicht so schwer ist, sie mit xattr zu implementieren. Kann das bitte auch jemand machen. :)

ZFS unterstützt nfsv4acls, also sollten wir IMHO zuerst nfsv4acls unterstützen und sehen, ob posix acls wirklich benötigt werden. Wenn ja, dann können wir herausfinden, wie man eine Zuordnung zwischen ihnen definiert.

Ich sehe keinen Grund, warum beides nicht möglich ist. Maxximino arbeitet derzeit daran, die xattr-Schnittstelle system.posixacl über eine gut dokumentierte Übersetzung zu unterstützen. Das Hinzufügen der system.richacl xattr-Schnittstelle kann unterstützt werden, wenn sie integriert ist und eine echte Werkzeugkette verfügbar ist.

"aktuell arbeiten" als wissenschaftliche und berufsbezogene Aufgaben es mir erlauben, aber mit hoher Priorität für "freie" Zeit.
Ich habe mir bereits den lizenzierten CDDL-Code von IllumOs angeschaut und einen Code gefunden, der NFSv4 <-> posix acl-Übersetzung durchführt. Aus Sicht der Korrektheit sollte es eine solide Basis sein. Einzelheiten auf Anfrage.

Ich weiß, dass Solaris nur zwei Kopien von chmod zur Verfügung stellt, um ACLs zu verwalten. Das ist leider sehr umständlich und klobig. Ich schlage vor, dass wir ein Hilfsprogramm, setzacl, getzacl oder ähnliches verwenden, um ACL-Anzeige- und -Änderungsfunktionen für zfs unter Linux bereitzustellen. Vorzugsweise sollte die Schnittstelle ähnlich (oder kompatibel mit) solaris chmod erstellt werden, möglicherweise verbessert, aber für beide zfs-Linux-Implementierungen standardisiert und vorzugsweise in der Lage sein, zukünftige Dateisysteme mit "nfs4"-Acls zu handhaben. (Wenn jemand erklären kann, warum sie nfs4-ACLs heißen, wäre das auch eine große Hilfe!)

Ich möchte hinzufügen, dass Samba-Benutzer vielleicht bei nfs4-ACLs bleiben möchten, nicht zuletzt, weil sie Feature für Feature den Windows NTFS-ACLs am nächsten kommen. Dies ist wichtig, wenn Sie Samba als Server für die Home- und Profilordner von Benutzern in einer Active Directory-Umgebung verwenden möchten, in der neuere Windows-Versionen nach bestimmten ACLs suchen. Außerdem war Windows-Interop in den Tagen von Sun eines der Designziele für ZFS, daher wäre es traurig, wenn es verschwinden würde ...

Das heißt, ich verstehe das Streben nach POSIX-Compliance voll und ganz.

aarcane - Siehe http://wiki.linux-nfs.org/wiki/index.php/ACLs für die Geschichte der NFSv4-ACLs.

Ich experimentiere gerade mit einer Samba 4 DC- und ZFS-CIFS-Freigabe; Das Basissystem ist Ubuntu 12.04.

XP Pro SP3-Clients können Active Directory (Benutzer und Computer) anzeigen und verwalten und NTFS-Berechtigungen richtig für Ordner festlegen, die von EXT4 freigegeben werden.

Von ZFS freigegebene Ordner werden durch CIFS nicht durchsuchbar, sobald Sie ihre Berechtigungen über die XP-GUI ändern (obwohl Sie weiterhin - wie erwartet - über die Befehlszeile des Servers darauf zugreifen können).

Ich nehme an, das liegt an den Problemen, die im obigen Thread beschrieben wurden? Alle Work-Around-Ideen werden dankbar angenommen.

Die Aktivierung des vollständigen NTFS-ACL-Administrators über Samba 4 wäre ein massiver Bonus für ZFS.

Kannst du bitte mehr Details zu deinem Problem posten? Genaue Samba4-Version, welchen Dateiserver verwenden Sie (smbd oder ntvfs) und alle relevanten Einstellungen? (zB verwenden Sie vfs_acl_xattr oder etwas ähnliches?)
Vielleicht ein anderes Problem öffnen, WENN dieselbe Samba4-Konfiguration über extY-Mount ohne "acl"-Option funktioniert.

Über die Manipulation von echten NFSv4 (NTFS-ähnlichen) ACLs durch Samba kann dies _auf saubere Weise_ erst erfolgen, nachdem "Rich ACL"-Patches in den Kernel eingebunden wurden.

Danke Maxximino.
Ich verwende Samba 4.0.0 alpha19.
Ich versuche nur, Dateien mit ntvfs zu Servern (sudo /usr/local/samba/sbin/samba -i -M single) - was Netlogon- und sysvol-Freigaben von ext4 und meine zfs-Freigaben von einem gespiegelten Laufwerkspaar mit aclinherit= . bedient Passthrough-Set.
Es wird kein vfs_acl_xattr-Modul verwendet.

"Über die Manipulation von echten NFSv4 (NTFS-ähnlichen) ACLs durch Samba, dies kann nur auf saubere Weise erfolgen, nachdem "Rich ACL"-Patches in den Kernel eingebunden wurden."

Soweit ich das verstanden habe, unterstützen die offiziellen Richacls-Patches nur EXT4 - meinen Sie damit, dass wenn ich zB opensuse verwende (mit standardmäßig enthaltenem richacl) oder richacls in ubuntu / debian patche, zfs+samba4+ntfs acls "einfach mit der Arbeit beginnen" sollte? "?

Ich habe dein Problem reproduziert.
Sie verwenden vfs_acl_xattr nicht explizit, aber Samba4 tut dasselbe "still". Es speichert seine ACLs in dem xattr namens "security.NTACL" (das Sie mit getfattr -n security.NTACL $FILENAME sehen und mit setfattr -x security.NTACL $FILENAME entfernen können).
Dieses Attribut wird nur von Samba berücksichtigt, nicht von irgendetwas im zfs/linux-Kernel. Da ein einfaches Perl-Programm, das Werte aus /dev/urandom in xattrs in zfs speichert, diese unbeschädigt zurücklesen kann, denke ich wirklich, dass es sich um ein Samba4-Problem handelt.
Das Problem tritt WAHRSCHEINLICH nur auf zfs auf, weil es auf anderen fs seine ACLs auf Posix-ACLs abbilden kann, anstatt xattrs zu verwenden.

Nein, es reicht nicht aus, einen Kernel einfach mit Rich-Acl-Patches zu patchen. Wenn diese Patches auf der Mainline landen, ist es möglich, die reichhaltige ACL-Unterstützung in zfs zu integrieren.

Ich baue gerade Samba 4 auf Suse; Ich glaube, ich wollte Ihre Reproduktion aus einem anderen Blickwinkel reproduzieren.
Hat mir den Schmerz erspart.

Vielleicht wäre eine vernünftige (kurzfristige) Problemumgehung, Dateien von zfs über eine stabile Samba-3-Umgebung bereitzustellen und sich beispielsweise gegen einen Samba-4-DC in einem anderen Linux-VServer zu authentifizieren?

Mittelfristig kann der Nutzen von ZFS-basierten CIFS-Shares in Kombination mit Samba 4 AD, die alle auf einem Linux-Betriebssystem mit hervorragender allgemeiner Hardware-Unterstützung _in derselben Maschine_ basieren, nicht überbewertet werden. Die Anwendungen für kleine Unternehmen / gemeinnützige Organisationen sind riesig.

Danke für die ganze Arbeit bisher.

Ich bin über folgenden Thread gestolpert:
https://lists.samba.org/archive/samba/2012-August/168660.html

Zusammenfassend lässt sich sagen, dass Samba 4 ein acl-Modul namens vfs_zfsacl hat, das auf Solaris verwendet wird, damit Samba die nativen ZFS-Acls verwenden kann. Wäre es möglich, dieses Modul mit zfsonlinux zu verwenden? Werden dem Benutzerbereich unter Linux die erforderlichen APIs zur Verfügung gestellt?

@kisg Das ist eine gute Frage, dies ist das erste, was ich vom vfs_zfsacl-Modul für Samba gehört habe. Einige müssen noch einiges an Arbeit machen, um festzustellen, welche Schnittstelle sie erwarten. Je nachdem, was es ist, können wir es möglicherweise zur Verfügung stellen. Wenn jedoch keine Übersetzung durchgeführt wird, haben Sie immer noch das Problem, dass Sie die ACLs auf der Linux-Box nicht verwalten können.

Ich habe kurz in die Quelle geschaut.
Sie finden die Samba v4-0-stable-Zweigversion von vfs_zfsacl.c hier: git.samba.org .

Es konvertiert einfach von der internen Samba-Darstellung in die native SunOS NFSv4 acl/facl-API. Diese API wird auch auf FreeBSD implementiert, indem ein dünner User-Space-Wrapper um seine eigene NFSv4-Acl-Implementierung herum verwendet wird.

Basierend auf dieser Analyse können wir diese Implementierung unter Linux nicht wiederverwenden. Wenn die richacl-Integration von zfsonlinux abgeschlossen ist, könnten wir stattdessen die librichacl-Bibliothek verwenden, um ein ähnlich einfaches (hoffentlich weniger als 1000 Zeilen) vfs_richacl-Modul für Samba zu erstellen.

Aus meinem flüchtigen Blick auf die richacl-Kernel-Patches scheint es, dass die Zfsonlinux-Integration sogar ohne tatsächliches Patchen des Kernels durchgeführt werden könnte, indem einfach die erforderlichen Teile (Datenstrukturen und xattr-Konvertierung) des richacl-Codes in den zfs-Baum für Kernel-Versionen gezogen werden, die nicht nativ unterstützen. Dies ist für uns wichtig, da wir (meine Firma) gerne einen Standard-Ubuntu-LTS-Kernel betreiben und nur zfsonlinux als zusätzliches Modul einbinden möchten.

Ich bin mir jedoch nicht sicher, ob richacl noch gepflegt wird (sein Repository wird nicht wirklich auf dem neuesten Stand gehalten) und auf dem Weg zur Aufnahme in den Vanilla-Kernel ist.

Ich habe den Autor des richacl-Patchsets kontaktiert. Er wies mich auf das folgende experimentelle richacl vfs-Modul hin: v4acls-experimental/samba.git

Es sieht also so aus, als ob fast alle Teile vorhanden sind (oder zumindest in experimenteller Form existieren), mit Ausnahme der richacl-Unterstützung in zfs selbst.

Vielleicht reicht die Portierung von libsunacl.c auf Linux von der Samba-Seite aus aus?

http://sourceforge.net/projects/libsunacl/

aber soweit ich das verstanden habe, wird "aclmode" auf zfsonlinux noch fehlen.

Ich weiß nicht einmal, warum wir noch keine ACL-Unterstützung haben. Warum haben
zfs acls nicht eingeschaltet? Ich kenne den Code für einen chmod und einen ls
exist.a getfacl style getzacl sollte mittlerweile bereitgestellt werden.Ich bin mir sicher
Es gibt jedoch einen guten Grund für das Fehlen von ACLs.
Am 15. Februar 2013 um 14:07 schrieb "franx" [email protected] :

Vielleicht reicht die Portierung von libsunacl.c auf Linux von der Samba-Seite aus aus?

http://sourceforge.net/projects/libsunacl/

aber soweit ich das verstanden habe, wird "aclmode" auf zfsonlinux noch fehlen.


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub an

zfs acl wird unterstützt
Prüfung:
Erstellen Sie eine Datei auf einer smb-Freigabe auf einem anderen Dateisystem mit aktivierter acl-Mount-Option, setzen Sie ACL unter Windows.

Verschieben Sie diese Datei auf ein zfsonlinux-Volume mit aclinherit=passthrough
acls bleiben erhalten..

Was atm keine Lösung hat, ist es in Samba zu tun.

Keines von acl_xattr oder acl_tdb funktioniert unter einer solchen Konfiguration korrekt, auf bsd verwenden sie vfs_zfsacl

durch libsunacl, die wie ein Übersetzer von zfs2bsd aussieht

Meine Frage ist vielleicht dumm, aber ich möchte ein klares Verständnis davon haben, ob wir ACL-Unterstützung haben oder nicht. Ich habe VBox Ubuntu Minimal Server 12.04 LTS erstellt, dann Ubuntu-zfs installiert, Pool w Befehle erstellt

Verlauf für 'mypool':
2013-05-05.15:12:49 zpool create -f mypool /dev/disk/by-id/ata-VBOX_HARDDISK_VB88a04e0d-d8d1e7a4

Historie für 'Panzer':
2013-04-30.13:44:54 zpool erstellen tank /root/vol1
2013-05-01.00:13:33 zfs set aclinherit=passthrough tank
2013-05-05.13:50:14 zfs set dedup=on tank

tank unterstützt setfacl ohne problem
mypool tut dies NICHT und sagt, dass der Betrieb nicht unterstützt wird.

Ich möchte ZFS mit Samba verwenden und muss den Zugriff mehrerer Benutzer auf Ordner kontrollieren. so wie das
root@server :~# setfacl -mg: USERS :--- test4v007/

Ich möchte den richacls-Patch für ZFS implementieren, aber da ich mit ZFS völlig unerfahren bin, wäre es schön, wenn einer der ZFSonLinux-Entwickler etwas Hilfestellung geben kann (meist in Form von Hinweisen und Diskussionen).

Ich würde dem gerne einen Schubs geben...

@behlendorf - Jetzt haben Sie eine stabile Version des Dateisystems, haben wir einen festen Zeitplan dafür, bis wann dies erledigt sein wird? Ich weiß, dass Sie den Meilenstein 0.8 erreicht haben, aber beim aktuellen Release-Tempo scheint es noch ein paar Jahre zu dauern - können wir es irgendwie vorziehen?

Wir möchten bei der Arbeit mit der Bereitstellung für unsere Profilspeicher-NAS-Server mit Samba vorankommen, aber keine ACLs zu haben, kann bedeuten, dass wir bei FreeBSD bleiben müssen, was wir wirklich nicht tun möchten, da unsere gesamte Erfahrungsbasis mit Linux liegt.

Ich hoffe, es ist nicht völlig offtopic.
Haben Sie Debian kFreebsd ausprobiert?

Es ist fast wie eine Art Linux..

@sopmot -

Also guter Gruß, danke, dass du mich auf den richtigen Weg gebracht hast - Entschuldigung für die Unhöflichkeit.

Ich schaue mir kfreebsd weiter an und es fehlen iscsi, nfsv4 und an
Äquivalent zur kvm-Virtualisierung. Ich meinte es ernst damit, es für root zu verwenden
bis diese Mängel offensichtlich wurden
Am 19. Mai 2013 um 9:50 Uhr schrieb "Tamas Papp" [email protected] :

Ich hoffe, es ist nicht völlig offtopic.
Haben Sie Debian kFreebsd ausprobiert?

Es ist fast wie eine Art Linux..


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/170#issuecomment -18120673
.

Das würde ich auch gerne angesprochen sehen. Leider habe ich heutzutage wenig Zeit (und ich kenne mich mit Low-Level- / Kernel-Zeug nicht aus), also kann ich nicht viel tun, um mir selbst zu helfen :( Wirklich, obwohl ich nur nach einem guten Weg suche bestimmte Berechtigungen für neue Dateien in bestimmten Verzeichnissen erzwingen; ich lege Dateien oft in einen öffentlich zugänglichen Ordner und es wäre schön, wenn sie automatisch mit gelockerten Berechtigungen eingerichtet werden könnten, da ich meine umask nicht wirklich auf etwas so einstellen möchte liberal für die meisten Dateien, die ich erstelle, die in meinem Home-Ordner landen. In OSOL/FreeBSD würde ich dies mit NFSv4-ACLs tun, obwohl ich offen für bessere Lösungen bin, wenn jemand Ideen hat. Das einzige andere, was ich denken kann of läuft einen Cronjob, der alle halbe Stunde rekursiv die Perms auf die relevanten Verzeichnisse setzt oder so, aber das ist so scheußlich unelegant! So ein Kludge :(

Zu Ihrer Information, damit die Leute nicht den gleichen Fehler machen wie ich - Debian kFreeBSD ist großartig für die ZFS-Unterstützung, aber die ACLs funktionieren immer noch nicht im Userland, Sie erhalten nur "Funktion nicht implementiert" - siehe Debian-Bug: http:// bugs.debian.org/cgi-bin/bugreport.cgi?bug=607573

@iamacarpet Es kann passieren, sobald jemand, der diese Funktionalität benötigt, Zeit hat, daran zu arbeiten. Derzeit haben die Haupttreiber des Projekts nicht viel Verwendung für ACLs, daher stehen sie ganz unten auf der Prioritätenliste. Aber nichts hindert jemanden, der diese Unterstützung braucht, daran, früher einzuspringen und es zu tun. Entschuldigung, aber es ist nur die Realität der Situation.

Hallo,

wir verwenden zfsonlinux in einer Backup-Appliance und sind der Meinung, dass ACLs für Integrationszwecke wichtig sind. Einige gängige Vorgänge wie das Ändern von Berechtigungen in einem freigegebenen ZFS-Volume von einem Windows-Computer sind erforderlich.

Ist ACL noch in der Roadmap?

Vielen Dank.

@n1mh Es ist für Version 0.8.0 geplant.

Dank @maxximino wurde die Unterstützung für Posix-ACLs implementiert. Ich habe Pull Request #1809 mit einer fast endgültigen Version des Patches geöffnet, die für umfassendere Tests bereit ist. Es besteht den ACL-Abschnitt der Posix Test Suite sauber und uns sind keine offenen Probleme bekannt.

Für diejenigen, die diese Funktionalität wünschen, wäre es sehr hilfreich, wenn Sie den vorgeschlagenen Patch mit einer realistischen Arbeitsbelastung testen könnten. Bitte überprüfen Sie, ob es sich in Ihrer Umgebung so verhält, wie Sie es erwarten würden. Posix-ACLs sind standardmäßig deaktiviert, können jedoch durch Festlegen der Eigenschaft _acltype_ im Dataset aktiviert werden.

zfs set acltype=posixacl pool/dataset

Posix-ACLs im Linux-Stil wurden als xattr implementiert und in Master eingebunden. Sie werden unabhängig von den nativen NFS-ACLs gespeichert und führen nicht zu Konflikten. Die neue Dataset-Eigenschaft acltype wurde hinzugefügt, um diese Funktionalität zu ermöglichen. Für die beste Leistung wird dringend empfohlen , sowohl xattr=sa zu setzen . Weitere Details finden Sie auf der aktualisierten Manpage:

       acltype=noacl | posixacl

           Controls  whether  ACLs  are  enabled and if so what type of ACL to
           use.  When a file system has the acltype property set to noacl (the
           default)  then  ACLs are disabled.  Setting the acltype property to
           posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
           cific  to  Linux  and are not functional on other platforms.  Posix
           ACLs are stored as an xattr and therefore will  not  overwrite  any
           existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
           are supported on Linux.

           To obtain the best performance  when  setting  posixacl  users  are
           strongly encouraged to set the xattr=sa property.  This will result
           in the Posix ACL being stored more efficiently on disk.  But  as  a
           consequence of this all new xattrs will only be accessable from ZFS
           implementations which support the xattr=sa property.  See the xattr
           property for more details.

Sollte ein Item acltype=nfs4 auch erkannt und gleich behandelt werden wie
noacl, aber aus Kompatibilitätsgründen akzeptiert?
Am 29.10.2013 15:05 Uhr, "Brian Behlendorf" [email protected]
schrieb:

Posix-ACLs im Linux-Stil wurden als xattr implementiert und in
Meister. Sie werden unabhängig von den nativen NFS-ACLs gespeichert und werden nicht
Konflikt. Die neue Dataset-Eigenschaft _acltype_ wurde hinzugefügt, um zu aktivieren
diese Funktionalität. Für die beste Leistung wird Ihnen dringend empfohlen
setze sowohl _acltype=posixacl_ als auch _xattr=sa_. Für weitere Details siehe die
aktualisierte Manpage:

   acltype=noacl | posixacl

       Controls  whether  ACLs  are  enabled and if so what type of ACL to
       use.  When a file system has the acltype property set to noacl (the
       default)  then  ACLs are disabled.  Setting the acltype property to
       posixacl indicates Posix ACLs should be used.  Posix ACLs are  spe-
       cific  to  Linux  and are not functional on other platforms.  Posix
       ACLs are stored as an xattr and therefore will  not  overwrite  any
       existing ZFS/NFSv4 ACLs which may be set.  Currently only posixacls
       are supported on Linux.

       To obtain the best performance  when  setting  posixacl  users  are
       strongly encouraged to set the xattr=sa property.  This will result
       in the Posix ACL being stored more efficiently on disk.  But  as  a
       consequence of this all new xattrs will only be accessable from ZFS
       implementations which support the xattr=sa property.  See the xattr
       property for more details.


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/170#issuecomment -27348094
.

Warum ist das geschlossen? acltype nfs4 ist _weit_ wichtiger als die nicht standardmäßigen, völlig veralteten, eingeschränkten POSIX-Entwurfs-ACLs. NFS-ACLs sind der Standard für ZFS auf anderen Plattformen und weitaus flexibler. Sie ermöglichen auch den nahtlosen Export sowohl auf NFSv4 als auch auf SMB, da die ACL tatsächlich sowohl NFS- als auch NT-ACLs gut zuordnet. POSIX-Entwurfs-ACLs funktionieren nicht gut.

POSIX-Entwurfs-ACLs gehen auch nicht gut mit Vererbung um, sondern geben nur einen Standard für neue Dateien an. NFSv4-ACLs sind der einzige Weg nach vorn.

@synnack Das Hauptproblem bei der Unterstützung von NFS-ACLs liegt nicht wirklich auf der ZFS-Seite. Wir haben all diese Funktionen beibehalten und sie werden intern verwendet. Das Problem liegt bei den Linux-Dienstprogrammen (getfattr, setfattr usw.), die eher auf POSIX als auf NFS-ACLs basieren. Es gab in der Vergangenheit Versuche, NFS-ACLs auf Linux zu bringen, aber meines Wissens war keine davon erfolgreich. Sofern sich die Dinge nicht in letzter Zeit geändert haben, ist dies das größte Hindernis.

Sicher, aber schauen Sie sich die Arbeit von Andreas Gruenbacher und Aneesh Kumar bei OpenSuSE an, sie liefern bereits Richacl-Patches aus.

Abgesehen davon, dass richacl keine NFSv4-ACLs sind, sind sie (etwas verrückt) das Ergebnis der Zusammenführung des NFSv4-Schemas mit POSIX-ACLs, die für ext4 entwickelt wurden und alle schlimmsten Teile der POSIX-ACLs, IIRC, beibehalten.

Was wir brauchen, ist eine geeignete Schnittstelle für NFSv4-ACLs, damit sie von Dateisystemen, die sie unterstützen, gesetzt werden können. Wohlgemerkt, es gibt mindestens einen weiteren Typ von ACLs, der (zumindest teilweise) von Linux unterstützt wird - AFS ACLs. Die Möglichkeit, mehrere Schemata zu unterstützen, ist also nicht verrückt, obwohl ich denke, dass wir möglicherweise eine Solaris-ähnliche API benötigen, um sie am besten zu unterstützen ...

Natürlich, wenn richacl dazu gebracht werden kann, alle Teile zu stoppen, die außerhalb von NFSv4 gehen, und vorausgesetzt, dass Userland Sie nicht verarscht (Hallo, POSIX ACL-Maskenbits!) Das sind viele Annahmen, um ehrlich zu sein.

Ich würde tatsächlich vorschlagen, eine IOCTL hinzuzufügen, die für Dateien auf ZFS zu diesem Preis gilt

Ja, ich bin mir nicht sicher, was die Jungs mit dem POSIX-Draft-ACL-Zeug schnüffeln, das in reichhaltigen ACLs zusammengeführt wird.

@behlendorf :

Das Problem liegt bei den Linux-Dienstprogrammen (getfattr, setfattr usw.), die eher auf POSIX als auf NFS-ACLs basieren. Es gab in der Vergangenheit Versuche, NFS-ACLs auf Linux zu bringen, aber meines Wissens war keine davon erfolgreich. Sofern sich die Dinge nicht in letzter Zeit geändert haben, ist dies das größte Hindernis.

Ich sehe, dass Distributionen das Paket "nfs4-acl-tools" für die NFS4-Acl-Verwaltung verwenden. Es verwendet nfs4_getfacl, nfs4_setfacl und nfs4_editfacl. Wenn ich diese gegen zfs ausführe, erhalte ich derzeit "Vorgang zum Anfordern des Attributs nicht unterstützt". Dies scheint mir die Art und Weise zu sein, wie Linux NFS4 tun wird. Jetzt brauchen wir nur noch eine Möglichkeit für die Tools und ZFS, sich gegenseitig zu erkennen.

@ghfields danke für den Kommentar, ich habe mich seit einigen Jahren nicht mehr mit nfs4 acls befasst, aber es sieht so aus, als würden sie mit den User-Space-Komponenten wirklich gute Fortschritte machen. Basierend auf einer flüchtigen Lektüre der nfs4-acl-tools-Quelle sieht es so aus, als ob die erwartete Benutzer-/Kernel-Schnittstelle über ein Xattr namens system.nfs4_acl läuft, das das rohe xdr-codierte acl enthält.

Damit dies funktioniert, müssen möglicherweise nur xattr-Handler für ein system.nfs4_acl xattr hinzugefügt werden, das zwischen der intern von ZFS gespeicherten nfs4-Acl und der von den Dienstprogrammen erwarteten Repräsentation übersetzt. Da NFSv4 der einzige Verbraucher davon ist, bietet der Kernel keine generische Funktionalität, die wir verwenden können, wir müssen die Funktionen schreiben, um diese Kodierung/Dekodierung durchzuführen.

Oberflächlich betrachtet sieht es sehr gut aus, diese Funktion zu erhalten. Ich fände es toll, wenn ein Entwickler dieses Feature in Angriff nehmen möchte.

Da dieses Problem mit der Implementierung der POSIX-Acls geschlossen wurde, sollte ein neues Problem speziell für NFS4-Acls erstellt werden? Oder soll dieser wieder geöffnet werden?

@ghfields kannst du dafür eine neue Ausgabe eröffnen. Das erleichtert die Verfolgung.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

chrisrd picture chrisrd  ·  65Kommentare

nivedita76 picture nivedita76  ·  78Kommentare

tycho picture tycho  ·  67Kommentare

vbrik picture vbrik  ·  108Kommentare

pwolny picture pwolny  ·  102Kommentare
bleepcoder.com verwendet öffentlich lizenzierte GitHub-Informationen, um Entwicklern auf der ganzen Welt Lösungen für ihre Probleme anzubieten. Wir sind weder mit GitHub, Inc. noch mit anderen Entwicklern affiliiert, die GitHub für ihre Projekte verwenden. Wir hosten keine der Videos oder Bilder auf unseren Servern. Alle Rechte gehören ihren jeweiligen Eigentümern.
Quelle für diese Seite: Quelle

Beliebte Programmiersprachen
Beliebte GitHub Projekte
Mehr GitHub Projekte

© 2024 bleepcoder.com - Contact
Made with in the Dominican Republic.
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.