vsftpd - How to lock users into a specified directory tree?

nyle · 02-09-2008, 08:02 AM

Hello,

I am trying to set up an intranet FTP server using vsftpd.

The goal is for a user to log in as themself (no anonymous access--uploaded files need to reflect their owner/group!) and be put into /var/ftp/pub by default. They should be able to go deeper into the tree (/var/ftp/pub/games) but not upward (/var/ftp/).

I have figured out how to make the user automatically go to /var/ftp/pub when logged in. The problem is that once logged in, they can see the contents of / if they traverse the filesystem. This is not what I want.

I tried setting chroot_local_user to yes, but that seems to negate the directive that specified the default directory-- / became the default directory after setting CLU to yes! From what I've observed, this directive would only work when trying to lock users into their /home directory anyway.

For an example of what I *am* looking to set up, check out ftp.microsoft.com (spare me

or mirror.nyi.net (CentOS mirror). On both sites, the user starts in "/" with a list of 10 or so folders they can access. They cannot go above "/" (obviously). The rest of the filesystem is not visible to the user.

Is vsftpd even capable of something like this, or do I need to start looking at other programs?

Thanks

jschiwal · 02-09-2008, 09:23 AM

Look in the vsftpd.conf manpage. There is an option to jail a user if their entry in /etc/password contains the string '/./'.

Also look into sftp. There was a post on this site last month about using rssh & sftp. If I remember correctly, one of the posters was the auther of the rssh shell patch.

Also see http://articles.techrepublic.com.com...5-6181828.html

nyle · 02-09-2008, 10:10 PM

That would be the passwd_chroot_enable option, but it doesn't really solve the problem. Perhaps I'm implementing it wrong, but using it jails the user to a single folder. In my case I could jail the user in /var/ftp/pub, but they would not be able to go to /var/ftp/pub/games.

The irony here is that this was an *extremely* simple affair using FileZilla in Windows; you could just select the directories you wanted to share and it was done. Clients could not access anything that wasn't explicitly permitted. Surely there is as simple a solution on Linux.

Any other ideas?

jschiwal · 02-10-2008, 11:28 AM

I made a couple changes in the vsftpd.conf file and tried it out myself. I was able to cd into subdirectories, but the /srv/ftp/users directory I used showed up as root (/) when I logged in.

Here is the vsftpd.conf file I tried:

Code:

dirmessage_enable=YES
anonymous_enable=NO
anon_world_readable_only=YES
syslog_enable=YES
connect_from_port_20=YES
pam_service_name=vsftpd
listen=YES
ssl_enable=NO
anon_mkdir_write_enable=NO
anon_upload_enable=NO
chroot_local_user=YES
ftpd_banner=Welcome message
idle_session_timeout=900
local_enable=YES
local_root=/srv/ftp/users
log_ftp_protocol=NO
max_clients=10
max_per_ip=3
pasv_enable=YES
pasv_max_port=40500
pasv_min_port=40000
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES
write_enable=YES
download_enable=NO

nyle · 02-10-2008, 06:01 PM

That works beautifully! Just like I had in mind.

Unfortunately I have no idea why your config worked and mine did not. I will have to reconcile my vsftpd.conf against yours and post my findings.

I'm surprised that the passwd_chroot_enable option wasn't even necessary.

As an aside for anybody else reading this, this configuration will not work if you run vsftpd through inetd-- you will need to remove the line "listen=yes" (learned this the hard way).
Furthermore I don't know if it was the client or server, but something didn't like the fact that all the booleans are in caps. A simple "cat /etc/vsftpd.conf | tr [:upper:] [:lower:] > /etc/vsftpd.conf1" made quick work of that though.

I do appreciate your efforts very much; now if only I can figure out why your config worked and mine behaved so differently.

Thanks!

jschiwal · 02-11-2008, 01:47 AM

Besides the configuration, check the permissions and ownerships of the directory and subdirectories, E.G. /var/ftp/pub. An ftp user will need execution bit permissions on the pub directory to be able to enter it, and write permissions of the directory to be able to create files there. You might also want to set the sticky bit on the directories to prevent users from deleting other user's files.

I need to correct or clarify my earlier post. There is a shell you can use (rssh) if you use sftp instead of vsftp, that prevents cd'ing to a higher directory than that listed in the person's home directory entry if the pattern contains (/./). You may be able to configure sshd_config to use vsftp for the ftp client, but that wouldn't prevent the user from then also having ssh shell access. The rssh default shell was written to control this. The 'r' stands for "restricted".

nyle · 02-11-2008, 06:34 PM

It was definitely a configuration issue. I modified your config to reflect my own local_root and that's what made it work. I had everything chmodded 3770 to begin with.

I looked over my config and couldn't find any differences, so I started over with a default config and tried setting everything up again. It seems to work now; I'm thinking I might have messed something up with chroot_local_user initially.

Thanks again for your help!