mod_vrootmod_vroot.c file for
ProFTPD 1.3.x, and is not compiled by default. Installation
instructions are discussed here.
The purpose of this module to is to implement a virtual chroot capability
that does not require root privileges. The mod_vroot module
provides this capability by using ProFTPD's FS API, available as of 1.2.8rc1.
The most current version of mod_vroot can be found at:
https://github.com/Castaglia/proftpd-mod_vroot.git
Please contact TJ Saunders <tj at castaglia.org> with any questions, concerns, or suggestions regarding this module.
2003-08-26: Thanks to Oskar Liljeblad for the elegant patch that added symlink support.
<VirtualHost>, <Global>
The VRootAlias directive is used to create an "alias" of a
directory outside of the chroot area into the chroot. The dst-path
parameter is a relative path, relative to the chroot area (i.e.
the directory in which the session starts). The src-path parameter,
on the other hand, is an absolute path, and may be to a file or
directory.
For example, you might map a shared upload directory into a user's home directory using:
<IfModule mod_vroot.c>
VRootEngine on
DefaultRoot ~
VRootAlias /var/ftp/upload ~/upload
</IfModule>
This will automatically create an "upload" directory to appear in the
chroot area (in this case, the user's home directory).
The VRootAlias directive is only needed for files/directories
that are going to be accessed by remote clients. It is not needed
for configuration files (e.g. PAM configuration files like pam_env.conf) needed by libraries. Using the VRootAlias for
such library configuration files is pointless and wasteful.
Note that this directive will not work if the
VRootServerRoot is used.
<VirtualHost>, <Global>
The VRootEngine directive enables the virtual chroot engine
implemented by mod_vroot. If enabled, the virtual chroot will
be used in place of the operating system's chroot(2). This
directive affects any DefaultRoot directives and any
<Anonymous> contexts within the server context in which
the VRootEngine directive appears.
<VirtualHost>, <Global>
The VRootLog directive is used to specify a log file for
mod_vroot's reporting on a per-server basis. The file
parameter given must be the full path to the file to use for logging.
<VirtualHost>, <Global>
The VRootOptions directive is used to configure various optional
behavior of mod_vroot.
Example:
VRootOptions allowSymlinks
The currently implemented options are:
allowSymlinks
Normally, any symlinks that point outside of the vroot area simply do
not work. When the allowSymlinks option is enabled, these
symlinks will be allowed. Note that by enabling symlinks, the efficacy
of the vroot "jail" is reduced.
<VirtualHost>, <Global>
The VRootServerRoot directive is used to configure a directory
to which the mod_vroot module will perform a real chroot.
The idea is that each <VirtualHost> can have its own
directory to which a real chroot(2) system call is made;
the user-specific home directories will be virtual roots underneath this
directory. Thus some measure of security, via the chroot(2)
system call, is provided by the kernel, while still allowing symlinked shared
folders among users of this <VirtualHost>.
For example:
<VirtualHost a.b.c.d>
VRootEngine on
VRootServerRoot /etc/ftpd/a.b.c.d/
VRootOptions allowSymlinks
DefaultRoot ~
...
</VirtualHost>
See also: VRootOptions
mod_vroot, go to the third-party module area in
the proftpd source code and unpack the mod_vroot source tarball:
$ cd proftpd-dir/contrib/ $ tar zxvf /path/to/mod_vroot-version.tar.gzafter unpacking the latest proftpd-1.3.x source code. For including
mod_vroot as a staticly linked module:
$ ./configure --with-modules=mod_vroot:...To build
mod_vroot as a DSO module:
$ ./configure --enable-dso --with-shared=mod_vroot:...Then follow the usual steps:
$ make $ make install