DefaultRoot, Symlinks and
Restricting Users' Directories
One of the most common questions for new users of ProFTPD is "How do I restrict my users to only certain directories?" or, phrased another way, "How can I put my users in a chroot jail?" As a common question, it definitely has a place in the FAQ. Many users, I fear, do not read the FAQ carefully, and so miss that section. The answer is ProFTPD's
directive, which accomplishes this functionality by using the
This configuration directive may appear in the
<Global>, and the "server config" (meaning
not in any
sections) configuration contexts. The most common configuration requested
is to restrict users to their home directories, which can be done simply
by adding the following line to your
~(tilde) is a Unix-ism that is expanded to the logging-in user's home directory. For slightly more complex setups, administrators may want to restrict only a subset of their users into home directories (or some other directory), but leave some privileged users unrestricted. For example, say you have your privileged users all as members of a group called
DefaultRoot's optional second parameter, a group-expression, can then be used, like so:
DefaultRoot ~ !ftp-specialThis says to
chroot()every user who is not a member of group
ftp-specialto their respective home directory, and:
DefaultRoot /path/to/dir group1,group2will
chroot()users who are members of both
/path/to/dir. More complex group-expressions can be used as needed.
Note that the execute bit (
--x) must be on in order to
chroot() a user into that directory. This bit is also needed
for a user to be able to
chdir into that directory.
There have been many questions on the ProFTPD user mailing list about why symlinked directories are not visible to
chrooted users (this
<Anonymous> users as well as users restricted using
DefaultRoot. This document is intended to clarify the issues and
discuss some ways of achieving what is commonly desired.
These issues are not specific to ProFTPD, but rather to the workings of a
Unix system. First, a brief review of how links work, and why
chroot(2) poses such a problem. Then a look at ways around
How Links Work
There are two types of links in Unix: hard and symbolic.
A hard link is a file that is, for all intents and purposes, the
file to which it is linked. The difference between a hardlink and the linked
file is one of placement in the filesystem. Editing the hardlink edits the
linked file. One limitation of hard links is that linked files cannot reside
on different filesystems. This means that if
/home are two different mount points in
/etc/vfstab), then a file in
/var/tmp cannot be
hardlinked with a file in
> pwd /var/tmp > ln /home/tj/tmp/tmpfile tmplink ln: cannot create hard link `tmplink' to `/home/tj/tmp/tmpfile': Invalid cross-device linkA symbolic link (also referred to as a "symlink") is a file whose contents contain the name of the file to which the symbolic link points. For example:
lrwxrwxrwx 1 root root 11 Mar 2 2000 rmt -> /sbin/rmtThe file
rmtcontains the nine characters
/sbin/rmt. The reason symbolic links fail when
chroot(2)is used to change the position of the root (
/)of the filesystem is that, once
/is moved, the pointed-to file path changes. If, for example, if
chroot(2)is used to change the filesystem root to
/ftp, then the symlink above would be actually be pointing to
/ftp/sbin/rmt. Chances that that link, if
chroot(2)is used, now points to a path that does not exist. Symbolic links that point to nonexistent files are known as dangling symbolic links. Note that symbolic links to files underneath the new root, such as symlinks to a file in the same directory:
> pwd /var/ftp > ls -l -rw-r--r-- 1 root root 0 Jan 16 11:50 tmpfile lrwxrwxrwx 1 root root 7 Jan 16 11:50 tmplink -> tmpfilewill be unaffected; only paths that point outside/above the new root will be affected.
A typical scenario is one where "
DefaultRoot ~" is
used to restrict users to their home directories, and where the administrator
would like to have a shared upload directory, say
/var/ftp/incoming, in each user's home directory. Symbolic
links would normally be used to provide an arrangement like this. As
mentioned above, though, when
chroot(2) is used (which is what
DefaultRoot directive does), symlinks that point outside the
new root (the user's home directory in this case) will not work. To get
around this apparent limitation, it is possible on modern operating systems to
mount directories at several locations in the filesystem.
To have an exact duplicate of the
/home/dave/incoming, use one of these commands:
mount --bind /var/ftp/incoming /home/bob/incoming mount --bind /var/ftp/incoming /home/dave/incomingor, alternatively:
mount -o bind /var/ftp/incoming /home/bob/incoming mount -o bind /var/ftp/incoming /home/dave/incoming
mount_null /var/ftp/incoming /home/bob/incoming mount_null /var/ftp/incoming /home/dave/incoming
mount -F lofs /var/ftp/incoming /home/bob/incoming mount -F lofs /var/ftp/incoming /home/dave/incoming
<Anonymous>directories, which also operate in a
chroot()ed environment. Also, it should be possible to mount specific files this way, in addition to directories, should you need to (a directory is just another file in Unix).
As usual, more information can be found by consulting the man pages for the appropriate command for your platform. The commands for other flavors of Unix will be added as needed.
In order to have these tricks persist, to survive a system reboot, the
/etc/vfstab) file may need to have
these mounts added. Consult your local
vfstab(4) for Solaris) man pages for more information.
Chroots and Remote Filesystems
If the chroot directories for your users happen to reside on an NFS partition, then you need to make sure that root privileges are not blocked (e.g. often referred to as "root squash") by the NFS mount. Otherwise, the chroot will fail.