[Kapitel 5] 5.2 Unterschiede der Dateisysteme

5.2 Unterschiede der Dateisysteme

Eine der bedeutendsten Angelegenheiten, die Samba korrigieren muss, ist der Unterschied zwischen Unix und Nicht-Unix-Dateisystemen. Das umschließt Fragen wie die Behandlung symbolischer Links, Hidden-Files und Punkt-Dateien. Zusätzlich können auch Dateirechte ein Problem bedeuten, wenn sie nicht richtig belegt sind. Dieser Abschnitt beschreibt, wie man Samba verwendet, um einige dieser ärgerlichen Unterschiede auszugleichen und sogar manch neue Funktionalität aus eigenen zuzusetzen.

5.2.1 Dateien verstecken und Veto-Dateien

Es gibt einige Fälle, wo wir dafür sorgen müssen, dass ein User eine Datei gar nicht sehen oder nicht darauf zugreifen kann. Ein anderes Mal wollen wir einen User nicht vom Zugriff auf eine Datei abhalten - wir wollen sie nur verstecken, wenn man den Inhalt des Verzeichnisses anschaut. Auf Windows-Systemen erlaubt ein Dateiattribut, Dateien in einer Ordnerliste zu verstecken. In Unix ist der traditionelle Weg, in einem Verzeichnis Dateien zu verstecken, ihnen einem Punkt (.) vorzusetzen. Das bewahrt Dinge wie Konfigurationsdateien oder Vorgaben vor dem Einsehen bei der Durchführung eines gewöhnlichen ls -Befehls. Einen User überhaupt vom Zugriff auf eine Datei auszuschließen, bedeutet Arbeit mit Rechten auf Dateien oder Verzeichnissen.

Die erste Option, die wir besprechen sollten, ist die logische hide dot files. Diese Option macht genau das, was sie sagt. Wenn sie auf yes gesetzt ist, behandelt die Option Dateien, die mit einem Punkt beginnen (.) als versteckt. Ist sie auf no gesetzt, sind solche Dateien immer zu sehen. Der wichtige Gedanke ist, dass die Dateien nur versteckt sind. Wenn der User ausgewählt hat, alle versteckten Dateien während des Betrachtens zu zeigen (z.B. bei den Ordner-Optionen den Menüpunkt unter dem Menü Betrachten in Windows 98 zu nehmen), wird man die Dateien noch sehen können, siehe Figur 5.2.

Figur 5.2: Versteckte Dateien in der Share [data]

Anstatt der einfachen Versteckmethode von Dateien, die mit einem Punkt beginnen, kannst du in Samba auch ein Muster aus einer Zeichenfolge zum Verstecken von Dateien festlegen, indem du die Option hide files anwendest. Nehmen wir z.B. an, dass wir das Folgende in unserer Muster-Share [data] eingetragen haben:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	hide files = /*.java/*README*/

Jeder Eintrag für diese Option muss mit einem Slash (/) beginnen, enden oder von den anderen getrennt sein, sogar wenn nur ein Muster angeführt ist. Diese Vereinbarung erlaubt Leerzeichen in Dateinamen. In diesem Beispiel würde das Share-Verzeichnis wie in Figur 5.3 erscheinen. Noch einmal: beachte, dass wir die Windows 98-Option gesetzt haben, versteckte Dateien im Fenster zu sehen.

Figur 5.3: Dateien verstecken auf der Basis von Dateinamen-Mustern

Wenn wir User daran hindern wollen, überhaupt Dateien zu sehen, können wir stattdessen die Option veto files benützen. Diese Option mit derselben Syntax wie die Option hide files bezeichnet eine Liste von Dateien, die von den Usern nie gesehen werden sollte. Ändern wir z.B. die Share [data] auf die folgende Weise:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	veto files = /*.java/*README*/

Die Syntax dieser Option ist identisch mit der Konfigurations-Option hide files: jeder Eintrag muss mit einem Slash (/) beginnen, enden oder von den anderen getrennt sein, sogar wenn nur ein Muster angeführt ist. Wenn wir das so machen, werden die Dateien hello.java und README einfach aus dem Verzeichnis verschwinden, und der User wird nicht mittels SMB darauf zugreifen können.

Dabei stellt sich eine andere Frage, die wir ansprechen müssen. Was passiert, wenn der User versucht, ein Verzeichnis mit Veto-Dateien zu löschen? Das ist der Punkt, wo die Option delete veto files auftaucht. Ist diese logische Option auf yes gesetzt, dann darf der User reguläre und gesperrte Dateien im Verzeichnis löschen, und das Verzeichnis selbst wird entfernt. Wenn die Option auf no steht, kann der User keine gesperrten Dateien löschen, und daher wird das Verzeichnis auch nicht gelöscht. Aus der Perspektive des User erscheint das Verzeichnis leer, kann aber nicht entfernt werden.

Die Direktive dont descend nennt eine Liste von Verzeichnissen, deren Inhalte für Samba nicht sichtbar sein sollten. Beachte, dass wir contents, nicht das Verzeichnis selbst. User dürfen in ein Verzeichnis als solches wechseln, aber sie dürfen den Verzeichnisbaum nicht weiter hinuntersteigen - sie werden immer einen leeren Ordner sehen. Verwenden wir diese Option mit z.B. einer mehr grundlegenden Form der Share, die wir früher in diesem Kapitel festgelegt haben:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	dont descend = config defaults

Zusätzlich wollen wir annehmen, dass das Verzeichnis /home/samba/data die folgenden Inhalte hat:

drwxr-xr-x   6 tom      users     1024 Jun 13 09:24 .
drwxr-xr-x   8 root     root      1024 Jun 10 17:53 ..
-rw-r--r--   2 tom      users     1024 Jun  9 11:43 README
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 config
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 defaults
drwxr-xr-x   3 tom      users     1024 Jun 13 09:28 market

Wenn der User dann zu der Share verbindet, würden er oder sie die Verzeichnisse in Figur 5.4 sehen. Nun, die Inhalte der Verzeichnisse /config und /defaults würden dem User leer erscheinen, auch wenn andere Verzeichnisse oder Dateien darin vorkommen. Zusätzlich können User keine Daten in den Ordner schreiben (was sie daran hindert, eine Datei oder einen Ordner zu erzeugen, mit demselben Namen wie eine (einer), die (der) schon existiert, aber unsichtbar ist). Wenn ein User so etwas versucht, wird er (sie) eine Meldung "Acces Denied" (Zugriff verboten) erhalten. dont descend ist eine administrative Option, keine Sicherheits-Option, und ist kein Ersatz für gute Dateirechte.

Figur 5.4: Inhalte der Share [data] mit dont descend

5.2.2 Links

DOS und NT-Dateisysteme haben keine symbolischen Links; Windows 95/98/NT-Systeme kommen dem stattdessen mit "shortcuts" nahe. Sobald darum ein Client versucht, einen symbolischen Link auf einer Share des Sambaservers zu öffnen, versucht Samba, dem Link zu folgen, um die Originaldatei zu finden, und lässt sie dem Client öffnen, wie wenn er oder sie auf einer Unix-Maschine wären. Wenn du das nicht erlauben willst, dann setz die Option follow symlinks:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	follow symlinks = no

Du kannst das testen, indem du ein Verzeichnis auf dem Unixserver innerhalb der Share erzeugst, als deren User du eingeloggt bist. Gib die folgenden Befehle ein:

% mkdir hello; cd hello
% cat "Das ist ein Test" >hello.txt
% ln -s hello.txt "Link to hello"

Das Ergebnis sind die zwei Dateien, die im Fenster in Figur 5.5 gezeigt werden. Normalerweise, wenn du auf eine der beiden klickst, bekommst du eine Datei, die den Text "Das ist ein Test" enthält. Nun, mit der Einstellung der Option follow symlinks auf no solltest du einen Fehler wie im Dialog von Figur 5.5 erhalten, wenn du auf "Link to hello" klickst.

Figur 5.5: Ein Fehler-Dialog beim Versuch, symbolischen Links zu folgen, wenn sie von Samba verboten wurden

Schließlich lasst uns die Option wide links besprechen. Steht diese Option auf yes, so erlaubt sie dem Client-User, symbolischen Links zu folgen, die ausserhalb des freigegebenen Verzeichnisbaums hinzeigen und Dateien oder Verzeichnisse auf dem anderen Ende des Links einschließen. Nehmen wir z.B. an, dass wir die Share [data] folgendermaßen modifizierten:

[data]
	path = /home/samba/data
	browseable = yes
	guest ok = yes
	writeable = yes
	case sensitive = no
	follow symlinks = yes
	wide links = yes

Solange die Option follow symlinks eingeschaltet ist, wird das Samba veranlassen, allen symbolischen Links außerhalb des gegenwärtigen Share-Baums zu folgen. Wenn wir eine Datei außerhalb der Share erzeugen (z.B. in jemandes Home-Verzeichnis) und dann in der Share einen Link auf sie anlegen, wie folgt:

ln -s ~tom/datafile ./datafile

dann kannst du die Datei in Tom's Verzeichnis öffnen gemäß den Rechten der Zieldatei.

5.2.3 Dateisystem-Optionen

Tabelle 5.4 zeigt eine Zusammenstellung der vorher diskutierten Optionen. Für die meisten empfehlen wir die Vorgaben, ausgenommen die in den folgenden Beschreibungen.

Tabelle 5.4: Konfigurations-Optionen für das Dateisystem
Option	Parameter	Funktion	Vorgabe	Bereich
`unix realname`	boolean	Liefert dem Client den vollen Namen des Unix-Users.	`no`	Global
`dont descend`	string (Liste von Verzeichnissen)	Enthält eine Liste von Verzeichnissen, deren Inhalte Samba für die Clients unsichtbar machen sollte.	Keine	Share
`follow symlinks`	boolean	Wenn auf `no` gesetzt, unterstützt Samba keine symbolischen Links.	`yes`	Share
`getwd cache`	boolean	Wenn auf `yes` gesetzt, wird Samba einen Cache für `getwd()` -Aufrufe benützen.	`yes`	Global
`wide links`	boolean	Wenn auf `yes` gesetzt, wird Samba symbolischen Links außerhalb der Share folgen.	`yes`	Share
`hide dot files`	boolean	Wenn auf `yes` gesetzt, werden versteckte Unix-Dateien wie versteckte Windows-Dateien behandelt.	`yes`	Share
`hide files`	string (Dateiliste)	Liste von Datei-Rechtemustern, zur Behandlung als versteckt.	Nichts	Share
`veto files`	string (Dateiliste)	Liste von Datei-Rechtemustern, nie zu zeigen.	Nichts	Share
`delete veto files`	boolean	Wenn auf `yes` gesetzt, werden Dateien gelöscht, die mit den `veto files` übereinstimmen, wenn das Verzeichnis, das sie enthält, gelöscht wird.	`no`	Share

5.2.3.1 unix realname

Einige Programme erfordern einen vollen Usernamen zum klaglosen Arbeiten. Ein Windows E-Mail-Programm z.B. muss oft einen Usernamen mit einem gegebenen Realnamen verknüpfen. Wenn deine System-Passwortdatei die Realnamen der User im GCOS-Feld enthält, weist die Option unix realname Samba an, diese Infomation an die Clients zu liefern. Ohne diese Option wird der Name des Users einfach seine oder ihre Login-ID sein. Wenn z.B. deine Unix-Passwortdatei die folgende Zeile enthält:

rcollins:/KaBfco47Rer5:500:500:Robert Collins:
/home/rcollins:/bin/ksh

und die Option in der Konfigurationsdatei ist:

[global]
	unix realname = yes

dann wird der Name Robert Collins an jeden Client geliefert, der den Realnamen des Users rcollins verlangt. Du musst dich typischerweise nicht um diese Option kümmern.

5.2.3.2 dont descend

Die Option dont descend kann verwendet werden, um verschiedene Verzeichnisse zu bezeichnen, die auf dem Client leer erscheinen sollten. Beachte, dass das Verzeichnis selbst noch erscheint. Nun, Samba wird dem Client-User nichts von den Inhalten des Verzeichnisses zeigen. Das ist keine gute Option zum Gebrauch als Sicherheits-Werkzeug (ein User könnte vielleicht einen Weg finden, sie zu umgehen); sie ist wirklich nur als eine Annehmlichkeit gedacht, Client-User vom Nachschauen in Verzeichnisse mit möglicherweise sensiblen Dateien abzuhalten. Siehe unser Beispiel früher in diesem Abschnitt.

5.2.3.3 follow symlinks

Diese Option, die vorher genauer besprochen wurde, kontrolliert, ob Samba einem symbolischen Link im Unix-Betriebssystem zum Ziel folgen wird oder ob er einen Fehler an den Client-User zurückschicken soll. Wenn die Option auf yes gesetzt ist, wird das Ziel des Links als die Datei interpretiert.

5.2.3.4 getwd cache

Diese globale Option legt fest, ob Samba einen lokalen Cache für den Unix Systemaufruf getwd() (get current working directory) verwenden sollte. Du kannst den Vorgabewert yes wie folgt überschreiben:

[global]
	getwd cache = no

Setzt man diese Option auf yes, so kann die Zeit, die zum Erkennen des Arbeitsverzeichnisses gebraucht wird, signifikant anwachsen, besonders, wenn die Option wide links auf no gesetzt wird. Du solltest normalerweise diese Option nicht ändern müssen.

5.2.3.5 wide links

Diese Option legt fest, ob der Client-User symbolischen Links folgen kann, die außerhalb des freigegebenen Verzeichnisbaums hinzeigen. Das schließt Dateien oder Verzeichnisse am anderen Ende des Links mit ein, solange die Rechte für den User stimmen. Der Vorgabewert für diese Option ist yes. Beachte, dass diese Option nicht unterstützt wird, wenn die Option follow symlinks auf no gesetzt ist. Eine Einstellung dieser Option auf no bremst smbd beträchtlich.

5.2.3.6 hide files

Die Option hide files liefert ein oder mehr Verzeichnis- oder Dateinamen-Einstellungen an Samba. Jede Datei, die mit dieser Einstellung übereinstimmt, wird von der Perspektive des Clients als eine versteckte Datei betrachtet. Beachte, dass dies einfach bedeutet, dass das DOS hidden-Attribut gesetzt ist, was bedeuten kann oder nicht bedeuten kann, dass der User sie gegenwärtig beim Browsen sehen kann.

Jeder Eintrag in der Liste muss mit einem Slash (/) beginnen, enden oder von den anderen getrennt sein, sogar wenn nur ein Muster angeführt ist. Das erlaubt das Vorkommen von Leerzeichen in der Liste. Sternchen können als Wildcard verwendet werden, um null oder mehr Zeichen zu ersetzen. Fragezeichen können nur exakt ein Zeichen vertreten. Ein Beispiel:

hide files = /.jav*/README.???/

5.2.3.7 hide dot files

Die Option hide dot files versteckt alle Dateien auf dem Server, die mit einem Punkt-Zeichen (.) beginnen, um die Funktionalität hinter einigen Shell-Befehlen nachzuahmen, die es an Unix-Systemen gibt. Wie hide files, diese Dateien, welche mit einem Punkt beginnen, haben das DOS hidden Attribut gesetzt, was nicht notwendigerweise garantiert, dass ein Client sie nicht sehen kann. Der Vorgabewert dieser Option ist yes.

5.2.3.8 veto files

Strenger als der Status der versteckten Dateien ist der Status, der von der Konfigurations-Option veto files geboten wird. Samba würde nicht einmal zugeben, dass diese Dateien existieren. Du kannst sie vom Client aus nicht auflisten oder öffnen. In Wirklichkeit ist das keine vertrauenswürdige Sicherheits-Option. Es ist eigentlich ein Mechanismus, um PC-Programme vor dem Löschen besonderer Dateien zu schützen, so wie eine zum Speichern der Quellgabelung einer Macintosh-Datei auf einem Unix-Dateisystem. Wenn Windows und Macs sich dieselben Dateien teilen, das kann schlecht informierte Power-User daran hindern, Dateien zu entfernen, welche die Mac-User brauchen.

Die Syntax dieser Option ist mit der Konfigurations-Option hide files identisch: jeder Eintrag muss mit einem Slash (/) beginnen, enden oder von den anderen getrennt sein, sogar wenn nur ein Muster angeführt ist. Sternchen können als Wildcard verwendet werden, um null oder mehr Zeichen zu ersetzen. Fragezeichen können nur exakt ein Zeichen vertreten. Ein Beispiel:

veto files = /*config/*default?/

Diese Option dient in erster Linie administrativen Zwecken - sie ist kein Ersatz für gut überlegte Dateirechte.

5.2.3.9 delete veto files

Diese Option weist Samba an, Veto-Dateien zu löschen, wenn ein User versucht, das Verzeichnis zu löschen, in dem sie enthalten sind. Der Vorgabewert ist no. Das bedeutet, wenn ein User ein Verzeichnis zu löschen versucht, das eine Veto-Datei enthält, dann wird die Datei (und das Verzeichnis) nicht gelöscht. Stattdessen wird das Verzeichnis bestehen bleiben und aus der Perspektive des Users leer erscheinen. Wird die Option auf yes gesetzt, werden Verzeichnis und Veto-Dateien gelöscht.


5.1 Browsing		5.3 Dateirechte und Attribute auf MS-DOS und Unix

Using Samba