Sie benötigen hierfür den WuFTPD. Dieser ist auf SuSE 6.4 enthalten. Es ist dringen angeraten, sich das Update von SuSE zu besorgen (siehe auch Einspielen von Updates und Patches), da der ausgelieferte WuFTPD schwere Sicherheitsmängel aufweist.
Sie müssen sicherstellen, daß der WuFTPD auch installiert ist. Bei SuSE ist standardmäßig der ProFTD zur Installation ausgewählt. Wenn der WuFTPD installiert ist, müßen Sie ihn als erstes aktivieren.
Der WuFTPD wird von inetd aus gestartet. Deshalb finden sich die Einstellungen zum Start in der Datei /etc/inetd.conf. Achten Sie darauf, daß dort die Option -a angegeben ist. Dadurch wird sichergestellt, daß die Datei /etc/ftpaccess verarbeitet wird. Die gesamte Zeile darf nicht auskommentiert sein, also kein "#" Zeichen am Anfang aufweisen (sie auch Erste Schritte nach der SuSE Installation).
Mit dem Kommando

killall -HUP inetd     (?!?!)

können Sie den inetd nach dem Ändern der inetd.conf-Datei neu starten, damit er die neuen Einstellungen kennt, und bei Bedarf den WuFTPD aufruft.

Der WuFTP kennt drei verschiedene FTP-Möglichkeiten: Anonymes FTP, Real FTP und Guest FTP. Anonymes FTP, ist der Zugriff mit dem Nutzernamen "anonymous" und der eigenen eMail-Adresse als Passwort. Der FTP Server gibt uns dann eine "chroot"-Umgebung vor, in der wir beliebig herunterladen können, und oft auch in ein Verzeichnis hochladen können. "chroot" heißt hierbei change root. Tatsächlich liegt das Verzeichnis, in dem wir uns austoben (bei SuSE 64) unter /usr/local/ftp. Wir können nicht höher in die Verzeichnis-Hierarchie wechseln, wenn wir per FTP eingeloggt sind. Uns wird dort vorgetäuscht, daß wir uns in / befinden. Das root-Verzeichnis wird also für diesen einen Login-Prozess woanders hin verschoben. Aus diesem Grunde benötigen wir an der Stelle, zu der es verschoben wird auch eine spezielle Verzeichnisstruktur und Kopien von einigen Unix-Kommandos.
Bei Real-FTP melden Sie sich mit einem tatsächlich auf dem System (in der /etc/passwd) vorhandenen Nutzernamen und mit dessen Passwort ein. Der FTP-Server loggt Sie nun zuerst in das entsprechende Home-Verzeichnis ein. Dieses Szenario habe ich in dem Beispiel mit der Windows-Freigabe und smbmount auch gezeigt. Der Nachteil ist aber der folgende. Wenn Sie so eingeloggt sind, dann können Sie sich tatsächlich auf der gesamten UNIX-Maschine bewegen. Sie können also auch zB. in das Verzeichnis /root wechseln (daß wir dort kein Datei-Listing bekommen, steht auf einem anderen Blatt). Gerade in dem genannten Beispiel ist dies aber unerwünscht. Viel schöner wäre es, wenn auch hier mit einer chroot-Umgebung gearbeitet werden könnte, sich der eingeloggte Nutzer nur in seinem Homeverzeichnis austoben könnte. Und genau das ist unter Guest FTP möglich, weshalb wir uns dies hier einmal genau ansehen wollen.

Ein Standard SuSE ermöglicht erst einmal kein Anonymous-FTP. Real FTP ist aber möglich. Wenn ich hier nur unter einem bestimmten Nutzernamen einigen Freunden Zugriff auf bestimmte Grafikdateien oder Sonstigem gewähren möchte, so ist es für mich ärgerlich, daß sie alledottedFiles (also Dateien die mit einem Punkt beginnen) sehen können, und daß sie sich in der Verzeichnisstruktur nach oben bewegen können.
Um dies zu verhindern, werden wir einen bestimmten Nutzer anlegen, der nur Guest FTP durchführen kann. Denn seine dotted Files können Sie gefahrlos löschen. Achten Sie darauf, falls sie einen bestehenden Nutzer Account jetzt ändern wollen, daß dieser nicht mehr mit einer Shell arbeiten kann, oder sonst etwas tun kann als FTP, wenn wir fertig sind. Optimalerweise legen Sie dazu also einen neuen Nutzer an. Tun Sie das mit Yast. Als Beispiel sei es der neue Nutzer "freunde", da ich ja Freunden die Zugangskennung mitteilen will sowie das spezielle Passwort. Als Shell weisen Sie dem neuen Nutzer /bin/false (Unter SuSE so vorhanden) zu. Ein Login ist damit für den Nutzer nicht möglich.
Um chroot-FTP zu ermöglichen, modifizieren Sie die /etc/passwd jetzt wie folgt. Die ursprüngliche Zeile:

freunde:x:516:100:fuer freunde:/home/freunde:/bin/false

ändern Sie bitte in

freunde:x:516:100:fuer freunde:/home/freunde/./graphics/:/bin/false

In diesem Fall bleiben wir bei dem Beispiel, daß in der Windows-Freigabe genannt ist, und in dem wir ebenfalls das Verzeichnis graphicsals interessantes Verzeichnis verwendet haben. Nur daß wir hier nicht den Nutzer frankie (ignorieren sie das, wenn sie nicht das smbmount kapitel gelesen haben), der ja auch Shell-Zugang haben soll, sondern  die neuen Nutzer freunde verwenden. Wenn Sie das wie hier gezeigt einstellen, dann muß also im home-Verzeichnis von freundeein Verzeichnis namens graphics existieren. Die Änderung betrifft das chroot. Das vor /./ genannte Verzeichnis ist das Verzeichnis, für daß das chroot gilt. In diesem müssen wir die später genannten Dateien anlegen. Das Verzeichnis nach dem /./ ist das Verzeichnis, in das der Nutzer nach erfolgreichem FTP-Login gleich mit einem automatischen chdir gebracht wird. Dort startet der FTP-Nutzer also seine Session. Das ist nützlich, weil man nicht allen Leuten erklären muß, was sie von dem ganzen Zeug zu halten haben, das sie zuerst auf dem Bildschirm sehen. Die "freunde" kommen ja zu einem bestimmten Zweck, und sehen so auf den ersten Blick, daß was sie auch sehen sollen, nämlich das graphics-Verzeichnis.
Es bietet sich direkt an, für derartige FTP-Logins auch gleich noch eine neue Gruppe anzulegen. Dazu fügen wir in die Datei /etc/group die folgende Zeile ein:

fclient::200:freunde

Danach Ändern wir die Gruppen-ID des Nutzers freunde in der /etc/passwd auch gleich von 100 auf 200:

freunde:x:516:200:fuer freunde:/home/freunde/./graphics/:/bin/false

So, daß Nutzermanagement für unseren Guest-FTP Login ist erledigt. Kommen wir nun zu den Dateien die ein chroot erwartet. Für eine chroot-Umgebung müssen bestimmte Systemdateien vorhanden sein, damit der FTP-Server Prozess arbeiten kann, da er ja selbst keinen Zugriff mehr auf das echte Wurzelverzeichnis / hat. Diese Verzeichnisse sind im betreffenden Fall also erst einmal anzulegen.
Hierbei ist sehr hilfreich, daß SuSE den Anonymous-FTP Zugriff in der Standard Installation zwar nicht gestattet, aber die notwendige Verzeichnisstruktur trotzdem erstellt hat. Es ist nämlich von OS zu OS und Distribution zu Distribution verschieden, wie diese Umgebung aussehen muß. Aber wir haben ja etwas, woran wir uns prima orientieren können. Die gewünschten Verzeichnisse liegen unter /usr/local/ftp. Das einzige Verzeichnis, welches wir nicht weiter beachten ist pub. Dort sind bei Anonymous-FTP die eigentlichen Dateien abgelegt. Aber wir haben dafür ja unser Verzeichnis /home/freunde/graphics.
Wenn Sie ls /usr/local/ftp machen, sehen Sie die Verzeichnisse, die sie jetzt unter /home/freunde anlegen müßen. Dazu wechseln Sie mit cd /home/freunde dorthin und geben dann folgendes ein:

mkdir bin dev etc lib msgs usr

wechseln sie jetzt in das Verzeichnis usr und geben folgendes ein

mkdir bin

So, die Verzeichnisse sind erstellt. Jetzt benötigen Sie Inhalte. Dazu nehmen Sie einfach die Inhalte aus den entsprechenden Verzeichnissen aus /usr/local/ftp. Es bietet sich an, diese zum Beispiel mit dem Midnight Commander (zum Start mc eingeben) zu kopieren. Wenn nicht, kopieren Sie die Inhalte mit cp /usr/local/ftp/bin/* /home/freunde/bin  etc. etc.
So kommen wir nun zu den Dateirechten. Bei dem ganzen Prozess haben wir Verzeichnisse und Dateien erzeugt, die root gehören. Wenn wir also im Verzeichnis /home/freunde stehen geben wir folgendes ein:

chmod 0555 *

danach gehen wir noch in das Verzeichnis usr und ändern die Verzeichnisrechte von bin auch darauf

cd usr
chmod 0555 *

So, jetzt setzen wir die Rechte für die Dateien. Fangen wir im Verzeichnis /home/freunde/bin an. Dort könnten jetzt Dateien wie ls, compress und tar stehen. Setzen Sie die Rechte alle auf 111:

chmod 111 *

Wenn Sie das Verzeichnis dev mittels Midnight Commander kopiert haben, enthält es bereits ein Geräte-File namens NULL. Wenn nicht, legen Sie es dort an

mknod -m 666 zero c 1 5

Als nächstes sind die Dateien unter /etc relevant. Dort müßen jetzt die Dateien group und passwd stehen. Die Rechte sollten bei root bleiben und die Inhalte sollten etwa so aussehen (für die passwd):

root:*:0:0:Superuser:/:bin/false
freunde:*:516:200::/graphics:/bin/false

im groupfile sollte es so aussehen:

fclient::200:freunde

also genau wie im normalen groupfile.
Jetzt legen Sie noch das Verzeichnis

mkdir /home/freunde/upload

an. Dies soll das einzige Verzeichnis sein, in das Uploads erlaubt sind. Mit chmod 3773 uploads setzen wir die Rechte noch freundlich.

So, kommen wir jetzt zum harten Teil. Die Datei /etc/ftpaccess. Das ist nur hart, weil wir beim ersten Betrachten nur Bahnhof verstehen. Ein man ftpaccess hilft da wie immer weiter. Aber wir haben ja ein konkretes Beispiel, für das wir die Änderungen hier mal zeigen. Also, die Original-Datei unter SuSE find ich erstmal grundsätzlich dünn. Da ist sicher einiges zu machen. Aber konzentrieren wir uns erstmal auf das wesentliche. Hier die Datei, wie ich Sie jetzt verändert habe:

email ftpadmin@localhost

class local real,guest *
class remote real,guest *

guestgroup fclient

limit all 10 Any /etc/ftpmsg.dead

readme README* login
readme README* cwd=*

shutdown /etc/shutmsg
message /welcome.msg login
message .message     cwd=*

upload /home/freunde * no
upload /home/freunde/uploads yes root root 0440 nodirs
upload /home/freunde/* /         no
upload /home/freunde/* /bin      no
upload /home/freunde/* /dev      no
upload /home/freunde/* /etc      no
upload /home/freunde/* /lib      no
upload /home/freunde/* /msgs     no
upload /home/freunde/* /uploads  no
upload /home/freunde/* /usr      no

compress  no all
tar       no all
delete    no fclient
overwrite no fclient
rename    no fclient
chmod     no fclient
umsak     no fclient

log commands real,guest
log transfers guest,real inbound,outbound

noretrieve core .notar passwd group ls
noretrieve /home/freunde/bin
noretrieve /home/freunde/dev
noretrieve /home/freunde/etc
noretrieve /home/freunde/lib
noretrieve /home/freunde/msgs
noretrieve /home/freunde/uploads
noretrieve /home/freunde/usr

(So, diese Einstellungen funktionieren zwar erstmal, aber noch nicht so wie erwartet. Wird überarbeitet und nachgereicht)
Uff, was haben wir damit getan ? Als erstes gibt man die eMail-Adresse des Administrators an. Das sollte eigentlich ftpadmin sein. Als nächstes werden Nutzerklassen definiert (man beachte, daß anonymous hier fehlt, weil wir so einen Zugriff zur Zeit nicht wollen).
Die nächste Anweisung ist entscheidend. Mit guestgroup fclients erhalten die Mitglieder der (systemweiten) Gruppe fclients nur noch Guest-FTP Zugang. Das heisst durch diese Anweisung wird dem FTPD mitgeteilt, daß er für den Server eine ChangeRoot Umgebung starten soll.
Mit limit wird der Zugriff zunächst beschränkt (siehe manpage).
Die readme und message Direktiven stehen für den Pfad, wo die entsprechenden Dateien zu finden sind. Damit ließe sich, wenn die Pfade denn korrekt gesetzt sind, und die entsprechenden Dateien vorhanden wären, eine gute Kommunikation mit dem Nutzer herstellen, indem ihm immer die passenden Kommentare zum entsprechenden Verzeichnis angezeigt werden. Dies wird hier auch nicht weiter diskutiert.
Die upload-Anweisungen sind entscheidend. Die erste verbietet erst einmal generell alle Uploads. Mit der zweiten wird dann konkret der Upload in das uploads Verzeichnis freigegeben. Die Dateien gehören danach root, und haben die genannten Dateirechte. Ferner dürfen keine Directorys im uploads Verzeichnis angezeigt werden. Unter den genannten Umständen funktionieren Uploads, aber der Nutzer sieht die Dateien in dem Verzeichnis nicht mal.
Die folgenden Upload-Anweisungen verbieten den Upload in die anderen Verzeichnisse unseres Homeverzeichnisses von freunde.
Zu den folgenden Befehlen läßt sich festlegen, ob die folgend genannten Klassen oder Gruppen diese ausführen dürfen, oder nicht. Aus Sicherheitsgründen darf in diesem Beispiel keiner etwas davon (Dafür müssen wir ab und an mal die Verzeichnisse aufräumen).
Schließlich wird das Logging komplett angeschaltet. Dies führt zu umfangreichen Log-Dateien. Wer diese zu groß findet, schaltet einfach das commands-Logging ab. Man sieht dann immer noch die Transfers.
Mit noretrieve legen wir schließlich fest, welche Dateien nicht heruntergeladen werden dürfen. Was mein Beispiel mit den Dateien angeht, funktioniert das auch. Meine Beispiele mit den Verzeichnissen funktionieren allerdings nicht (ich hatte sie aus einem anderen Beispiel). Hmm. Das lösen wir noch.

Abgesehen davon funktionierte bei mir nach dieser Vorgehensweise der Zugriff über Guest FTP problemlos. Die User kamen nicht mehr über das Verzeichnis freunde in die Reste des Dateisystems hinaus. Und für den Zugriff ist dennoch ein bestimmter Nutzername und ein bestimmtes Passwort erforderlich. Somit stehen die Daten auch nicht der ganzen Welt offen.

Weitere Hinweise finden Sie vielleicht auch noch unter: Developer Shed