Vererbung von ext3-/ext4-Gruppenrechten

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht – und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige – wenn auch rekursive – Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems – “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” – siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung
n
Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse

samba – unix extensions bug?

Vor kurzem habe ich ca. 2 Stunden damit verbracht, mich mit einem vermutlichen Fehler in der Samba-Server-Version 3.2.7 unter Kernel 2.6.27 herumzuschlagen. (Die Kernelversion galt sowohl für den betroffenen Server wie auch die Linux-Clients).

Der Fehler bestand darin, dass “force create mode” und “force directory mode” Einstellungen des Samba-Servers ignoriert wurden, wenn User von unseren Linux-Clients aus Dateien/Verzeichnisse im Share anlegen wollten. Das hatte bei uns in der Praxis insofern Folgen, als die reibungslose Arbeit in der Gruppe u.a. von den Rechten der erzeugten Dateien abhing.

Die “force…”-Einstellungen waren gerade deshalb gesetzt worden, damit weder Windows- noch Linux-User der Samba-Shares über die Rechte-Einstellungen nachdenken mussten.

Das Problem im Detail und die Bedeutung der “unix extensions”

Ich habe für einen Share auf einem Samba-Server folgende Einstellungen vorgegeben:

[aux]

comment = aux
inherit acls = Yes
path = /samba/ann_aux
read only = No
create mask = 0664
force create mode = 0664
force user = myuser

Dieser Share wird in unserem Netz – wie gesagt – nicht nur von Win-XP Clients (natürlich in einer virtuellen Umgebung unter Linux) aus benutzt, sondern auch von Anwendern auf reinen Linux-Systemen. Dabei stellten wir dann fest, dass für einen berechtigten Linux-User zwar die “force user”-Vorgabe ausgeführt wurde, die Dateirechte jedoch immer auf “rw-,r–,r–“ gesetzt wurden, statt wie erwartet (“OR” – Kombination der Berechtigungs-Bits!) auf “rw-,rw-,r–“.

Der Rechtekamm “rw-,r–,r–“ entsprach nicht den “force create mode”-Einstellungen des Servers, sondern vielmehr den umask-Einstellungen für den betreffenden User auf dem Linux-Client.

Dagegen funktionierten die obigen Einstellungen auf einem deutlich älteren Samba-Server für ein anderes Share. Was also war der Unterschied zwischen den Servern? Nach einigem Suchen im Internet und Vergleichen kam ich dann dahinter, dass die Option “unix extensions” auf dem neueren Server gesetzt ist – defaultmäßig auf “yes”.

Dieser Parameter steuert für CIFS Shares die Anzeige und Nutzung von Linux-Rechten im Zusammenspiel zwischen Samba-Servern und Linux/Unix-Clients. Ich zitiere von “http://wiki.ubuntuusers.de/Samba_Server/smb.conf” :

CIFS Unix Extensionsunix extensions = yes

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Dieser Parameter ermöglicht durch z.B. Samba Client/cifs auch auf dem Client die Original Dateirechte und Zeitstempel zu sehen und zu verwenden. Standardmäßig ist diese Option aktiviert; sie sollte nur bei Problemen mit diesen Extensions deaktiviert werden.
Die Einstellung kann nur für den gesamten Server geändert werden; unterschiedliche Einstellungen für einzelne Freigaben sind vom Server aus nicht möglich.

Weiter findet man unter “http://wiki.ubuntuusers.de/Samba_Client_cifs” folgende Ausführungen

Sind die CIFS-UNIX-Erweiterungen aktiv (auf dem Samba-Server: unix extensions = yes, Standard), so werden die echten Besitz- und
Zugriffsrechte zwischen Server und Client übertragen. Ändert man auf dem Client mittels chmod oder chown oder über den Eigenschaften-Dialog der GUI die Rechte, ist die Änderung ebenso auch auf dem Server und auf allen anderen Clients wirksam, die auf die Freigabe zugreifen.
Die Angaben in der Datei /etc/samba/smb.conf auf dem Server legen dabei den Rahmen fest, in dem Zugriffsrechte auf dem Client Gültigkeit haben. Ist z.B. eine Freigabe in smb.conf nur zum Lesen freigegeben, können für sie von keinem Client aus Schreibrechte festgelegt werden. Ist sie aber in smb.conf auch für Schreibzugriffe freigegeben, kann sie von jedem Client aus mittels chmod für “nur lesen” eingeschränkt werden. Ebenso können Freigaben, die auf dem Server den Status “nur lesen” haben, aber in smb.conf mit Schreibrechten eingetragen sind, vom Client aus mit Schreibrechten versehen werden.
Die UNIX-Erweiterungen haben Vorrang vor anderen Angaben für Besitz- und Zugriffsrechte. Sollten in der Mount-Befehlszeile oder im Eintrag in /etc/fstab solche Angaben vorhanden sein, so werden diese bei aktiven UNIX-Erweiterungen ignoriert.

Unter “http://us1.samba.org/samba/docs/man/manpages-3/smb.conf.5.html” liest man

unix extensions (G)
This boolean parameter controls whether Samba implements the CIFS UNIX extensions, as defined by HP. These extensions enable Samba to better serve UNIX CIFS clients by supporting features such as symbolic links, hard links, etc… These extensions require a similarly enabled client, and are of no current use to Windows clients.
Default: unix extensions = yes

Für Interessierte erwähne ich auch noch, dass auf dem Linux-Client beim Mounten eines CIFS-Shares auch ein Kernel-Parameter zur Nutzung der “unix extensions” gesetzt wird (bzw. gesetzt werden kann). Man werfe dazu nach dem Mounten des Samba-Shares einen Blick in das Verzeichnis “/proc/fs/cifs” und dort in die Datei “/proc/fs/cifs/LinuxExtensionsEnabled”. Ein

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

schaltet auf dem Client die Nutzung der vom Samba-Server angebotenen Unix-Extensions ab.

Soviel zur Theorie. Tatsächlich funktionieren die “Unix extensions” im Prinzip auch so wie vorgesehen – wenn man mal das “force create mode” außer Acht läßt :

  • Die User- und Gruppenrechte auf dem Samba-Server werden auf dem Linux-Client korrekt angezeigt. (Natürlich müssen auf dem Server und dem Client die gleichen UIDs und GIDs gesetzt sein wie auf dem Linux-Client!).
  • Jede Rechteänderung auf dem Linux-Client wird auf den Server übertragen.
  • Auch von MS Win-Clients aus funktioniert alles so wie vorgesehen – sogar das “force create mode” wird hier richtig ausgeführt.

Mein Problem besteht/bestand also darin, dass bei aktivierten “unix extensions” auf dem Samba-Server das gesetzte “force create mode” ignoriert wird, wenn man Dateien des Shares über einen Linux-Client anlegt. Das hätte ich schon aus Konsistenzgründen zu älteren Versionen des Samba-Servers nicht unbedingt so erwartet.

Die (vorrübergehende) Lösung

Probeweise habe ich den Samba-Server-Parameter “unix extensions” dann auf “no” gesetzt.

Danach wurden die Rechte von Files, die von Linux-Clients neu erzeugt wurden, tatsächlich wieder “korrekt” – d.h. gemäß der “force create mode”-Vorgaben – gesetzt. (Das Gleiche funktioniert natürlich auch, wenn man die entsprechenden Paramter für den Rechtemodus von Verzeichnissen benutzt.)

Blöd ist nur, dass die gewünschten und korrekt gesetzten User- und Gruppen-Rechte der Dateien auf dem Samba-Server nun natürlich nicht mehr auf den Linux-Clients angezeigt werden. Das war ja eigentlich der Sinn der “unix
extensions”. Aber damit kann man leben, wenn einem das Erzwingen von Rechten wirklich wichtig ist.

Eine Philosophie-Frage oder ein Bug ?

Nach diesen Erkenntnissen fragt man sich nun: Ist das eigentlich ein Bug ? Ich habe dazu zumindest einen Hinweis im Internet gefunden:

http://www.mail-archive.com/samba@lists.samba.org/msg99935.html und
http://www.mail-archive.com/samba@lists.samba.org/msg99936.html.

Natürlich könnte man aber auch wie folgt argumentieren: Wenn jemand die “unix extensions” benutzt, dann deshalb, weil man die Rechte auf dem Linux/Unix-Client selbst manipulieren will und soll. Irgendwie ist das ja der Kern der Sache. Also darf der User nicht voraussetzen, dass der Server die Rechtepolitik schon regeln wird. In meinem Fall hatte ich das auf Grund meiner Kenntnis des “force create mode”-Parameters explizit angenommen.

Andererseits:

Welche Chance hat ein Samba-Admin denn, wenn er trotz globalem “unix extensions” für bestimmte Shares auch für die User auf Linux-Clients vorgegebene Rechtekämme erzwingen will oder muss ? Lokal kann er ja für das betroffene Share die “unix extensions” nicht außer Kraft setzen – er muss auf dem Server also “force create mode” verwenden ! Aber das wird dann leider ignoriert !

Letztere Argumentation führt mich zu der Meinung, dass hier tatsächlich ein Bug vorliegt. Deshalb meine Aufforderung an die Samba- und Kernel-Profis: Bitte ändern – falls noch nicht geschehen !

 

Unison – Synchronisation mit GUI

Die gestrige Frage meiner geschätzten Gattin, wie ich es denn eigentlich so schnell schaffen würde, ein für unser Geschäft wichtiges Verzeichnis zwischen einem Linux-PC und einem Linux-Server, einem Windows XP-Laptop und einem anderen Linux-PC abzugleichen, ist vielleicht auch für andere Linux-User interessant.

Mein Freund und Konsolen-Liebhaber Michael würde nun antworten: “rsync”. Ich bin aber ein fauler Mensch. Und gerade im Konfliktfall muss man die Arbeitsweise und die Antworten von Rsync schon recht gut verstehen. Michael würde nun weiter sagen: Na, dann schreib dir halt ein Script. Meine Antwort darauf ist: Das haben andere schon gemacht – plus eine GUI dazu entwickelt.

Ein Beispiel für eine nette Applikation in diesem Umfeld stellt meiner Meinung nach “Unison” dar. Ich liste mal kurz die für mich wichtigen Eigenschaften auf:

  • Unison benutzt rsync, ist damit relativ schnell und vermittelt zwischen den Welten Linux, Unix, Mac OX und Windows.
  • Unison hat eine leicht zu überblickende und leicht zu bedienende graphische Oberfläche.
  • Unison erlaubt die Organisation der Abgleichvorgänge über Profile.
  • Unison gleicht Verzeichnisse natürlich auf Wunsch rekursiv ab.
  • Unison zeigt vor dem Abgleich an, was sich geändert hat.
  • Unison stellt Abgleichkonflikte in verständlicher Weise dar und gibt die Möglichkeit diese Konflikte pro Datei zu lösen.
  • Unison kann zusammen mit ssh benutzt werden.
  • Unison funktioniert auch über das Internet.
  • Unison funktioniert auch lokal – die abzugleichenden Verzeichnisse können auf ein und demselben Rechner liegen.

Letzteres ist besonders in Kombination mit NFS, Samba und smb4k interessant. Wenn keine größeren Sicherheitsanforderungen im lokalen Netz vorliegen und man die entsprechenden Rechte hat, hängt man die Laufwerke/Directories des Fremdrechners, auf dem sich das abzugleichende Verzeichnis befindet, einfach in das eigene Filesystem ein und führt dann den Abgleich durch. Das geht rasch und bequem.

Unison hat aber auch einen großen Nachteil – es funktioniert nicht, wenn der UTF8-Zeichensatz für Verzeichnis- oder Dateinamen ausgenutzt wird. Leider ! Wenn man aber im abzugleichenden Bereich diszipliniert mit konventionellen Dateinamen (ASCII 7) arbeitet, steht dem Einsatz von Unison als Synchronisationstool nichts im Wege – auch nicht für Arbeitsgruppen im Firmenumfeld.

Ein weiterer “Nachteil” ist ggf. der, dass man einen Abgleich zwischen mehreren Systemen durch sukzessive paarweise Abgleichvorgänge herbeiführen muss.

Dennoch: Einen Blick und einen Testlauf ist das einfach zu installierende Tool auf jeden Fall wert !