当为特定目的设置 FTP 帐户时 - 例如作为共享数据文件的放置点 - 似乎明智的做法是仅允许用户访问特定目录，而不允许查看更广泛的文件系统。
特别是在 *nix 系统上，每个用户通常都具有对许多系统文件的读取权限，例如/etc/passwd。FTP 守护程序通常允许您通过在登录时执行来隐藏这些文件chroot，以便用户处于虚拟的“监狱”中。
但chroot并非为安全措施而设计[网站似乎瘫痪了，因此存档副本]，甚至会引入自身的安全问题；因此，vsftpd限制此功能这样您只能chroot进入只读目录，然后用户必须导航到子目录才能执行任何写入操作。FTPD软件警告了该问题但没有提供替代方案，并且 PureFTPD 要求创建各种特殊文件才能使用chroot。
在我看来，FTP 访问根本没有理由映射到操作系统的文件系统访问概念；与 HTTP 守护程序一样，FTP 守护程序可以根据一组配置规则“重写”所有请求。如果您向 Apache Web 主机询问路径，它/会将其映射到目录中定义的目录DocumentRoot，而不是主机操作系统的当前/目录。
我的问题是，任何 *nix FTP 守护进程是否都使用这样的“重写”机制（或其他限制访问的方式），如果没有，那么有什么根本原因吗？
注：与这个现有的问题，但答案主要讨论是否使用chroot，而不是完整的替代方案。
答案1
http://www.ietf.org/rfc/rfc959.txt
我假设规范没有规定“目标”或服务器端必须指向特定类型的文件系统。如果不深入研究，我怀疑任何人都可以编写一个以任何合理方式监禁用户的守护进程，并且仍然可行。
或者，像 selinux 这样的程序可能能够将 ftp 用户限制到某些目录，而无需更改 ftp 守护进程。