Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jun 2003 15:34:25 +0100
From:      Jez Hancock <jez.hancock@munk.nu>
To:        FreeBSD ISP List <freebsd-isp@freebsd.org>
Subject:   proftpd, mass virtual hosting and symlinks
Message-ID:  <20030604143425.GB88470@users.munk.nu>

next in thread | raw e-mail | index | archive | help
Hi all,

Our webserver serves a large number of domains and the partitioning
scheme is setup like this:

/home - contains all shell related items for users (we allow shell logins)
/www - contains all documentroots for the server

A typical user's documentroot resides in:

/home/user/web/example.com/www/

which is a symlink to

/www/example.com/www

The idea was to save time on httpd requests by serving files from a
dedicated partition and similar issues also exist for
suexec cgi-bin trees and logfile trees.

The problem then is that when a user logs in via proftpd, if we use
'DefaultRoot ~' to chroot the users to their home directories, the user
is unable to follow the symlink to their web docroot(s) because of the
old chestnut with chrooting disallowing symlinks out of the chroot root
directory.

I've read through the manual for proftpd, particularly this:
http://proftpd.linux.co.uk/localsite/Userguide/linked/chroot-symlinks.html

which suggests instead of symlinking, mount each (currently symlinked)
directory in the target directory, something like:

mount_null /www/example.com/www /home/user/web/example.com/www

Questions:
Is proftpd a viable option for mass vhosting given this type of
partitioning scheme?  If so, how would I configure proftpd to handle symlinks
whilst still not allowing users to break out of their home directory?

If proftpd is not the best option - what other ftpd are recommended?  I
understand PureFTPD implements a 'quasi' chrooting system via a module
mod_vroot - is this a better option (proftpd also appears to have
support for mod_vroot, but docs are sparse)?

TIA,
Jez



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030604143425.GB88470>