When setting up an FTP account for a specific purpose - e.g. as a drop-point for sharing data files - it seems sensible to give the user access only to the particular directory, and no view of a wider file system.
On *nix systems, in particular, every user generally has read access to a lot of system files such as /etc/passwd. FTP daemons generally allow you to hide these by executing a chroot on login, so that the user is in a virtual "jail".
But chroot was not designed as a security measure [archive copy as site seems down], and can even introduce security problems of its own; for this reason, vsftpd restricted this feature such that you can only chroot to a read-only directory, and the user must then navigate into a sub-directory to perform any write operations. ProFTPD warns of the problem but offers no alternative, and PureFTPD requires various special files to be created in order to even use a chroot.
It seems to me that there is no fundamental reason for the FTP access to map to the OS's notion of filesystem access at all; like an HTTP daemon, an FTP daemon could "rewrite" all requests according to a set of configuration rules. If you ask an Apache web host for the path /, it maps that to the directory defined in the DocumentRoot directory, not to the host OS's current / directory.
My question is, does any *nix FTP daemon use a "rewriting" mechanism like this (or some other way of limiting access), and if not, is there a fundamental reason?
Note: there is some overlap with this existing question, but the answers primarily discuss whether to use chroot or not, rather than complete alternatives.
