
При настройке учетной записи FTP для определенной цели, например, в качестве точки сброса для обмена файлами данных, представляется разумным предоставить пользователю доступ только к определенному каталогу и не предоставлять доступ к более широкой файловой системе.
В частности, в системах *nix каждый пользователь обычно имеет доступ на чтение ко многим системным файлам, таким как /etc/passwd
. FTP-демоны обычно позволяют скрыть их, выполнив команду chroot
при входе в систему, так что пользователь оказывается в виртуальной «тюрьме».
Ноchroot
не был разработан как мера безопасности[архивная копия, так как сайт, похоже, не работает], и даже может создавать проблемы безопасности; по этой причине vsftpdограничил эту функциютаким образом, что вы можете перейти только chroot
в каталог, доступный только для чтения, а затем пользователь должен перейти в подкаталог, чтобы выполнить любые операции записи.ProFTPDпредупреждает о проблеме, но не предлагает альтернативы, а PureFTPD требует создания различных специальных файлов даже для использования chroot
.
Мне кажется, что нет никаких фундаментальных причин для того, чтобы доступ FTP отображался на представление ОС о доступе к файловой системе вообще; как и HTTP-демон, FTP-демон может «переписывать» все запросы в соответствии с набором правил конфигурации. Если вы запросите веб-хостинг Apache о пути /
, он сопоставит его с каталогом, определенным в DocumentRoot
каталоге, а не с текущим каталогом ОС хоста /
.
Мой вопрос: использует ли какой-либо FTP-демон *nix механизм «перезаписи» (или какой-либо другой способ ограничения доступа), и если нет, то есть ли на это фундаментальная причина?
Примечание: есть некоторое совпадение сэтот существующий вопрос, но в ответах в первую очередь обсуждается, стоит ли использовать тот chroot
или иной вариант, а не предлагаются полные альтернативы.
решение1
http://www.ietf.org/rfc/rfc959.txt
Я предполагаю, что спецификация не говорит, что 'destination' или серверная сторона должны указывать на определенный тип файловой системы. Не вдаваясь в подробности, я подозреваю, что кто угодно мог бы написать демона, который сажает пользователей в тюрьму любым разумным способом и все равно был бы жизнеспособным.
В качестве альтернативы, что-то вроде selinux может ограничивать пользователей FTP определенными каталогами без необходимости изменения демона FTP.