Chroot’ing a user is always a good idea from a security perspective, but by default it leaves usability lacking.

For example a web development department quite rightly is using individual logins, with each developer able to access each of their site directories, in a non chroot environment.

The downside? the can also browse pretty much the entire server, and each others directories …

So rather than some extensive and long winded chmoding or directories, we need to chroot them and still preserve access to the shared directories …

But how?

In this case the shared resource will be /home/shared

First of all for security and chrooting purposes make the following changes to /etc/vsftpd/vsftpd.conf

anonymous_enable=NO
chroot_local_user=YES

Now reload vsftpd: /etc/init.d/vsftpd

Create a test user (in this case buzz):

useradd buzz -d /home/buzz
passwd buzz

Remove the user’s shell access (and subsequently sftp/scp) by editing /etc/pass wd (remove the space between pass wd, wordpress is breaking when I try to post it properly)

replace

buzz:x:123:123::/home/buzz:/bin/bash

with

buzz:x:123:123::/home/buzz:/sbin/nologin

Test the FTP session:

[root@buzz ~]ftp xxx.xxx.xxx.xxx
Connected to xxx.xxx.xxx.xxx.
220 (vsFTPd 2.0.1)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (xxx.xxx.xxx.xxx:buzz): buzz
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>ls
227 Entering Passive Mode (10,99,1,1,123,97)
150 Here comes the directory listing.
drwxrwxr-- 4 48 48 4096 Mar 27 15:00 www
226 Directory send OK.
ftp> cd /home/shared
550 Failed to change directory.
ftp> cd ./www
550 Failed to change directory.
ftp> quit
221 Goodbye.

In the example above www is a symlink to /home/shared, as can be seen symlinking does not bypass the chroot settings.

What you need to do is use the “bind” option of the mount command (as root or a sudo’er):

mkdir /home/buzz/shared
mount --bind /home/shared /home/buzz/shared

NOTE: –bind is double dash bind NOTE: to reverse the bind (i.e. if you bind the wrong folder) umount /path/to/binded/folder

Now re-test the ftp session:

ftp xxx.xxx.xxx.xxx
Connected to xxx.xxx.xxx.xxx.
220 (vsFTPd 2.0.1)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (xxx.xxx.xxx.xxx:buzz): buzz
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (10,99,1,1,123,97)
150 Here comes the directory listing.
drwxrwxr-- 4 48 48 4096 Mar 27 15:00 www
drwxrwxr-- 4 48 48 4096 Mar 27 15:12 shared
226 Directory send OK.
ftp> cd /home/shared
550 Failed to change directory.
ftp> cd ./www
550 Failed to change directory.
ftp> cd ./shared
250 Directory successfully changed.
ftp> quit
221 Goodbye.

The user now is in a chroot’ed environment, but can still access the share resources you specify, by binding them.

FAQ:

Why remove the users SSH / SCP access?

SCP/SFTP at the time of writing has no logging facility, making it next to impossible to find out who uploaded / overwrote a file in the shared resource at any given time.

(UPDATE 19/07/2010: https://blog.oneiroi.co.uk/linux/enable-logging-in-the-sftp-subsystem)

By forcing FTP all transactions will appear in the xfer log.

There are mods for SCP out there to allow logging, however you can use them at your own risk I do not recommend using them on a customer facing environment.

Why would I want to “chroot” the user?

Change

chroot_local_user=YES

to

chroot_local_user=NO

and reload vsftpd, now login to ftp hand try to get out of your home directory,

you will notice you can pretty much browse the entire file system, and depending on the setup write and delete files owned by anyone in the same group as that user.

By chroot’ing the user you are reducing the potential for things to go wrong on your server, as you add more and more users it reduces the “sys admin” time incurred due to user error.

NOTE: Remember to put

chroot_local_user=YES

back and reload vsftpd!

Disclaimer:

You break it, it’s not my fault!

If you run into problems just leave a comment.