
Wenn Sie ein FTP-Konto für einen bestimmten Zweck einrichten – z. B. als Ablagepunkt zum Teilen von Datendateien –, ist es sinnvoll, dem Benutzer nur Zugriff auf das jeweilige Verzeichnis zu gewähren und keine Ansicht eines größeren Dateisystems.
Insbesondere auf *nix-Systemen hat grundsätzlich jeder Benutzer Lesezugriff auf viele Systemdateien wie z.B. /etc/passwd
. FTP-Daemons erlauben es in der Regel, diese zu verbergen, indem sie chroot
beim Login ein ausführen, so dass sich der Benutzer in einem virtuellen „Gefängnis“ befindet.
Aberchroot
wurde nicht als Sicherheitsmaßnahme konzipiert[Kopie archivieren, da die Site nicht erreichbar zu sein scheint] und kann sogar eigene Sicherheitsprobleme mit sich bringen; aus diesem Grund ist vsftpdDiese Funktion ist eingeschränktSo können Sie nur chroot
auf ein schreibgeschütztes Verzeichnis zugreifen und der Benutzer muss dann in ein Unterverzeichnis navigieren, um Schreibvorgänge auszuführen.ProFTPDwarnt vor dem Problem, bietet aber keine Alternative, und PureFTPD erfordert die Erstellung verschiedener spezieller Dateien, um überhaupt eine verwenden zu können chroot
.
Meiner Ansicht nach gibt es keinen grundsätzlichen Grund dafür, den FTP-Zugriff überhaupt dem Dateisystemzugriffskonzept des Betriebssystems zuzuordnen. Wie ein HTTP-Daemon könnte ein FTP-Daemon alle Anfragen gemäß einer Reihe von Konfigurationsregeln „umschreiben“. Wenn Sie einen Apache-Webhost nach dem Pfad fragen /
, ordnet er diesen dem im DocumentRoot
Verzeichnis definierten Verzeichnis zu, nicht dem aktuellen /
Verzeichnis des Host-Betriebssystems.
Meine Frage lautet: Verwendet irgendein *nix-FTP-Daemon einen solchen „Umschreibe“-Mechanismus (oder eine andere Möglichkeit zur Zugriffsbeschränkung) und wenn nicht, gibt es dafür einen grundsätzlichen Grund?
Hinweis: Es gibt einige Überschneidungen mitdiese bestehende Frage, die Antworten diskutieren jedoch in erster Linie über die Verwendung chroot
oder Nichtverwendung und stellen keine vollständigen Alternativen dar.
Antwort1
http://www.ietf.org/rfc/rfc959.txt
Ich gehe davon aus, dass die Spezifikation nicht besagt, dass das „Ziel“ oder die Serverseite auf einen bestimmten Dateisystemtyp verweisen muss. Ohne mich zu sehr in die Materie einzulesen, vermute ich, dass jeder einen Daemon schreiben könnte, der Benutzer auf vernünftige Weise einsperrt und trotzdem noch brauchbar wäre.
Alternativ kann etwas wie Selinux FTP-Benutzer möglicherweise auf bestimmte Verzeichnisse beschränken, ohne dass eine Änderung am FTP-Daemon erforderlich ist.