I'm setting up on my VPS a vsftpd, and i don't want users be allowed to leave they're ftp home directory. I'm using local_user ftp, not anonymous, so I added:


I've read in a lot of forum post, that this is unsecure.

  1. Why is this unsecure?
  2. If this is unsecure because of using ssh to join to my VPS as well, then I could just lock out these users from sshd, right?
  3. Is there an other option for achiving this behaviour of vsftpd? ( I dont want to remove read permissions on all folder/files for "world" on my system )

3 Answers 3


Check here for VSFTPD's FAQ for the answer your looking for. Below is the important excerpt that I think will answer your question.

Q) Help! What are the security implications referred to in the "chroot_local_user" option?

A) Firstly note that other ftp daemons have the same implications. It is a generic problem. The problem isn't too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system's libc might want to open locale config files or other settings...

  • Thanks for that, I didn't know all that myself. Learned something! +1 Feb 22, 2012 at 22:00
  • 7
    Actually I came here after reading the FAQ because I don't understand this worrying statement: "The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user.". Presumably this would only be the case if vsftpd had a security flaw (à la buffer overflow)??? How does running vsftpd with users chroot'ed to their home dir make this scenario more likely? Please explain...
    – sxc731
    Mar 2, 2017 at 21:06

The problem is that you can't both use local accounts and also disable those accounts from shell login. If you set their login shell to /bin/nologin, it won't let you login with vsftpd either.

A better and more secure FTP daemon would be Pure-ftpd. Look it up, it's available from the EPEL repository, and it allows to create virtual users. The server uses a common user/group to set all permissions for the home folders of the users and "maps" the virtual users to that user when it logs in to deal with permissions. That's more secure, and you don't have to deal with openssh login security.

Pure-ftpd also supports a whole lot of features such as quotas, ratios, and such. Much better than vsftpd.

Here's a simple tutorial on how to install it and configure a basic virtual user: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd-in-centos/

If you read the full doc (which you should) you'll know that the -d switch when creating the virtual user is an auto-chroot to that directory for that user.

  • I use the AllowUsers user1 user2 directive in my sshd_config, where i don't allow the ftp_user1 to login with ssh, still user ftp_user1 is able to login with ftp. So it's working as intented, but still my main question open, why is it unsecure?
    – p1100i
    Feb 22, 2012 at 14:11
  • 4
    Yes it will! You just need to add the "non-shell" to /etc/shells. On many systems either /bin/false or /bin/nologin exists in /etc/shells. If the shell is there, vsftpd will indeed let you login, also with chroot_local_user enabled. Feb 22, 2012 at 19:47
  • 1
    I stand corrected then. Thanks for pointing it out! Feb 22, 2012 at 21:58

When chroot’ed to /some/dir/, the filesystem becomes effectively confined to that directory. Thus, any program attempting to open/etc/some_file effectively opens /some/dir/etc/some_file.

When /some/dir/ is writable, a malicious user can insert a maliciously crafted /some/dir/etc/some_file into it.

The resulting degree of insecurity depends on the underlying software being aware of chroot’ing or not. vsFTPd surely is (as mentioned in the FAQ above), but some library underneath may not.

  • but it does not answer the question, why would it be insecure using chroot
    – djdomi
    Nov 4, 2021 at 18:02
  • @djdomi I edited my answer to specify "a maliciously crafted /some/dir/etc/some_file". The resulting degree of insecurity depends on the underlying software being aware of chrooting or not. vsFTPd surely is, but some library underneath may not. Nov 6, 2021 at 10:04
  • add these ibfos to the answer not to a comment!
    – djdomi
    Nov 6, 2021 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.