Um die schöne neue Domäne zu administrieren, kann man die klassischen Administrationswerkzeuge von Windows verwenden. Diese werden als Teil eines aktuellen Windows-Server-Betriebssystems mitgeliefert, stehen aber auch als nachinstallierbares Paket namens "Remote Server Administration Tools" für Windows-7- und Windows-8-Clients zur Verfügung. Das Anlegen neuer Benutzer erfolgt dann beispielsweise über das Tool
»Active-Directory-Benutzer und -Computer
«
.
Das gute alte Samba Web Administration Tool SWAT ist leider konzeptionell mit Samba 4 nicht mehr sinnvoll zu vereinbaren und zusammen mit Samba 3 gestorben. Momentan existiert noch kein Ersatz dafür, sodass die einzigen Administrationstools momentan die von Windows sind. Samba 4 stellt allerdings eine Python-API bereit, um die Entwicklung solcher Tools zu vereinfachen.
Nach dem Anlegen zweier Benutzer
»herbert
«
und
»otto
«
folgt der Test, ob auch openATTIC sie schon kennt:
root@benrime:~$ getent passwd herbert herbert:*:11110:10513::/home/SAMBA/herbert:/bin/bash root@benrime:~$ getent passwd otto otto:*:11109:10513::/home/SAMBA/otto:/bin/bash
Das ist schon ein gutes Zeichen. Diese Benutzer können sich von jetzt an auf den Windows-Clients einloggen. Nun sollen auf openATTIC ein Volume und eine CIFS-Freigabe entstehen. Das passiert in der
»smb.conf
«
beispielsweise mit einem neuen Abschnitt:
[tank] path = /tank available = yes browseable = yes guest ok = no writeable = yes
Man beachte dabei, dass zum Thema Berechtigungen hier nichts steht. Diese Informationen werden komplett über Windows konfiguriert, indem ein Administrator die Freigabe im Windows-Explorer öffnet und Berechtigungen vergibt. Damit das sauber funktioniert, sind allerdings zwei Dinge vonnöten: ein Dateisystem mit Unterstützung für erweiterte Attribute und die Zeile
»vfs objects = acl_xattr
«
in der Datei
»smb.conf
«
des Storage.
Windows unterstützt eine Vielzahl von Berechtigungen, die für Shares und die darin befindlichen Ordner und Dateien sehr fein abgestuft vergeben werden können ( Abbildung 2 ). Der Permissions-Mechanismus unter Linux ist im Vergleich dazu geradezu lachhaft: Unterstützt werden hier die Berechtigungen "Lesen", "Schreiben", "Ausführen" für die Rollen "Besitzer", "Gruppe" und "Rest der Welt". Aus Sicht eines Windows-Admins ist das keine Rechteverwaltung, sondern ein schlechter Scherz.
Diese beiden Welten miteinander zu verbinden, ist daher alles andere als einfach, aber nötig: Falls Samba nicht die einzige Möglichkeit ist, auf die Daten zuzugreifen, sondern auch lokale Logins auf dem Server oder eine NFS-Freigabe vorgesehen sind, ist sicherzustellen, dass die eingestellten Zugriffsrechte sich nicht auf diesem Weg umgehen lassen. Daher reicht es nicht, die Berechtigungen einfach in einer Datenbank zu speichern, sondern das Linux-Dateisystem muss einbezogen werden.
Zu Beginn übertrug Samba die passenden Windows-Berechtigungen auf Linux-Flags und ignorierte den Rest. Diese Lösung ist natürlich unbefriedigend, sodass der nächste Schritt in der Unterstützung von Posix-ACLs bestand. Damit besteht zumindest die Möglichkeit, Berechtigungen gezielt für einzelne User (auch wenn sie nicht der Besitzer sind) und einzelne Gruppen festlegen zu können ( Listing 6 ).
Listing 6
ACLs
Dies ist ein Fortschritt, aber ausreichend ist es leider trotzdem nicht: Windows kennt nämlich nicht nur "Lesen, Schreiben, Ausführen", sondern auch ausgefallene Berechtigungen wie "Unterordner und Dateien löschen, den Ordner selbst aber nicht".
Diese Berechtigungen lassen sich in Linux derzeit im Dateisystem nicht abbilden. Dennoch ist es erforderlich, dass sie zumindest in der Windows-Welt erhalten bleiben und dort umgesetzt werden. Dazu nutzt Samba erweiterte Dateiattribute, die es erlauben, innerhalb bestimmter Namensräume beliebige Variablen mit einer Datei zu assoziieren ( Listing 7 ).
Listing 7
Extended Attributes
Erweiterte Attribute bieten also die Möglichkeit, beliebige Metadaten zu einer Datei speichern zu können. Samba (genauer gesagt das
»vfs_acl_xattr
«
-Modul) nutzt diese Möglichkeiten nun, um Berechtigungen speichern zu können, die anders nicht abbildbar sind:
$ getfattr -n security.NTACL /tank/herbert/ # file: tank/herbert/ security.NTACL=0sAwADAAAAAgAEAAI...
Dabei gibt es allerdings eine kleine Schwierigkeit: Nicht alle Dateisysteme unterstützen diese Mechanismen, insbesondere ZFS unter Linux unterstützt sie leider nicht. Unter Solaris und FreeBSD schafft hier das Modul
»vfs_zfsacl
«
Abhilfe, dieses existiert unter Linux jedoch nicht.
Man kann zwar auf das Modul
»vfs_acl_tdb
«
ausweichen, das Berechtigungen in einer Datenbankdatei speichert. Auch dieses Modul bietet optional die Anpassung der Posix-ACLs an, sodass bei sorgfältiger Konfiguration auch hier keine Probleme bei anderweitigem Zugriff zu erwarten sind. Jedoch skaliert diese Lösung nicht so gut wie die Verwendung erweiterter Attribute, weil Datenbankzugriffe hier schnell zum Flaschenhals werden können. Weiterhin sind Snapshots, Hochverfügbarkeit und Failover nicht so einfach zu realisieren. Falls man Features braucht, wie ZFS sie bietet, sollte man also auch über den Einsatz von Btrfs nachdenken.