[oclug] Re: ProFTP

Dan Cardamore wombat at hld.ca
Mon Feb 12 15:21:49 EST 2001


www.proftpd.org is an excellent resource obviously, and this question is
in their FAQ.  Here is its output:

5.12 How can I limit users to a particular directory tree?

For general open access you can use an <Anonymous> directive context
block, possibly in combination with a UserPassword/AnonRequirePassword
directive.

However if you wish to jail an entire group (or groups) of users, you
can use the DefaultRoot directive. DefaultRoot lets you specify a root
jailed directory (or ' ' for the user's home directory), and an optional
group-expression argument which can be used to control which groups of
users the jail will be applied to. For example:

...
<VirtualHost myhost.mynet.foo>
DefaultRoot ~
...
</VirtualHost>
This creates a configuration where all users who log into
myhost.mynet.foo are jailed into their home directories (cannot chdir
into a higher level directory). Alternatively, you could:
...
<VirtualHost myhost.mynet.foo>
DefaultRoot /u2/public users,!staff
...
</VirtualHost>

In this example, all users who are members of group 'users', but not
members of group "staff" are jailed into /u2/public. If a user does not
meet the group-expression requirements, they login as per normal (not
jailed, default directory is their home). You can use multiple
DefaultRoot directives to create multiple jails inside the same
directive context. If two DefaultRoot directives apply to the same user,
ProFTPD arbitrarily chooses one (based on how the configuration file was
parsed).

Security Implications

The DefaultRoot directive is implemented using the chroot(2) system
call. This moves the "/" (or root) directory to a specified point within
the file system and jails the user into this sub-tree. However this is
not the holy grail of security, a chroot jail can be broken, it is not a
trivial matter but it's nowhere near impossible. DefaultRoot should be
used as part of a general system of security not the only security
measure.

A more detailed discussion on this subject and on the breaking of chroot
jails has been written by Simon Burr

Non-root server issues

The chroot() system call will not work under a non-root ftp server
process, the call requires root privaliges. Without them it simply
doesn't work, there doesn't appear to be any checking in the code of the
uid/gid before calling chroot so using DefaultRoot in such a setup will
cause the server to fail.

Symlinks

Symlinks will not work from within a chrooted area. The reason should be
clear from a casual inspection of the nature of the chroot command. It
is not possible to have a symbolic link to a directory which can't be
reached beacuse it's outside of the current chroot. Work arounds to
allow access to other parts of the file system include exporting the
part of the filesystem to be accessed from inside the chroot and
mounting via NFS, using hard file links or (on Solaris) using lofs to
mount the directory via the loopback.

mount -Flofs /home/data1 /ftp/data1
mount -Flofs /home/data2 /ftp/data2


Dan

On Mon, Feb 12, 2001 at 02:55:00PM -0500, Collin McCrank wrote:
> Hello,
> 
> I have another question regarding the setup of proftp.
> 
> Is it possible to restrict users who logon from cd'ing to a directory
> above the /home/ftp directory?
> 
> I have my users home directories set to /home/ftp and I want to make
> sure that they aren't able to cd to /home or anything else other than
> the directories in /home/ftp.
> 
> Are there any directives in proftp that can accomplish this, I have
> taken a quick look and havn't been able to find anything.
> 
> Or is there another way of accomplishing this.
> 
> Thanks again
> Collin


________________________________________________________________
 Dan Cardamore          wombat at hld.ca         http://www.hld.ca
 GnuPGP Key:            mailto:wombat at hld.ca?subject=sendpgpkey
 Email Stats:           http://www.hld.ca/~wombat/emailStats
 Opensource projects:   http://www.hld.ca/opensource
 My Groupware project:  http://www.gwpeople.com
________________________________________________________________



More information about the OCLUG mailing list