-   Linux - Security (
-   -   Vsftpd and chroot. (

Maris-S 10-09-2012 06:29 AM

Vsftpd and chroot.

I configured vsftpd with locking users to their home directories. Now I see that vsftpd do not allow by default to make user root directory writable, because of some security reasons related to glibc. After reading some articles found with google, I found option:


but now I'm thinking, if it's already safe enough to use it, or better to avoid this? Making some subfolders in users home directories would not be best option.

I'm using:

Slackware 14,
glibc 2.15,
vsftpd 3.0.2.

Thanks in advance!

bathory 10-09-2012 06:40 AM

If you don't want to create some "upload" directories in your users' homedirs, then you should use in vsftpd.conf the following


Maris-S 10-09-2012 08:03 AM

Thank you for your answer Bathory, but I think I was not very clear with my question. In general I found this option and it works fine for me, it suppose to work since vsftpd 3.0.0, but main question was - if it's secure enough? I found quite a lot of warnings in internet and vsftpd documentation about possible security issues when chroot_local_user is enabled, but there is no detailed description about it. Problem mainly is glibc related. I'm not so sure yet, but it looks like it's possible that FTP daemon under particular conditions can consider users chrooted home directory like normal root directory and e.g. read some config file etc/my_conf which is in users home directory.

Here is some quotes about it.


If set to YES, local users will be (by default) placed in a chroot() jail in their home directory after login. Warning: This option has security implications, especially if the users have upload permission, or shell access. Only enable if you know what you are doing. Note that these security implications are not vsftpd specific. They apply to all FTP daemons which offer to put local users in chroot() jails.

Default: NO


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...
Mostly it's written that this is small risk, but I can't find info on what conditions this security issue can be used? Maybe I even don't have such conditions in server configuration, maybe even glibc already don't have this bug, but I'm not sure.

bathory 10-09-2012 08:44 AM

I would say chroot() is quite secure as long as the user does not have shell access to the system.
Besides, ftp is an insecure protocol per se, so if you're concerned so much about security, better consider another way for your users to transfer files (like ftps or sftp/scp)


Maris-S 10-10-2012 02:42 AM

Thanks Bathory one more time. :)

Well, yes, there is no shell access for FTP users, I disabled it by specifying /bin/false shell for them, so I think it's OK and I will use it like this, though I will keep searching detailed info about this security issue.

Yes, I know that would be better to encrypt data which are being sent by FTP, but at this time it is not so important, I'm more worried about server security itself.

jsaravana87 10-10-2012 03:59 AM

Hi Maris-S,


I'm more worried about server security itself.

Instead of disabling the shell of ftp user .You are configured vsftpd with virtual user.Even it gives you more security and you cannot able to make login via ssh using virtual vsftpd user

These the link you have to look for configure vsftpd (Virtual user)

Maris-S 10-10-2012 06:33 AM

Hi Arun5002!

Yes, virtual users is one of the options and I'm still thinking if I will use system users or virtual users, didn't decide yet. :) Though virtual users has the same security issue I described in previous posts as this issue is not for users itself. In general it is not even vsftpd issue, the same is for ProFTPD, to be more precise issue is in glibc. But anyway thanks for your answer.

mmheera 10-10-2012 01:15 PM

Hi Maris-S,

I guess it has more to do with the security issue of chroot() in general. Chroot() is not 100% secure of course and it has its own vulnerabilities. But breaking out of jail requires root permission. And there are a few things to be taken care of to make the it more secure.In the following short article you can find them:

Best Practices for UNIX chroot() Operations

And if you are interested, here is also an article about breaking out of jail:

How to break out of a chroot() jail

It also says: "FreeBSD 4.x and above have a better chroot() system call".

Hope it helps.


sneakyimp 10-10-2012 01:41 PM


Originally Posted by Maris-S (Post 4801878)
Yes, I know that would be better to encrypt data which are being sent by FTP, but at this time it is not so important, I'm more worried about server security itself.

I would remind you that uploaded files may often contain sensitive credentials. If your users are uploading PHP or ASP.NET files to a web root for some domain, then it will be possible to execute files on your server. I would imagine SFTP or FTPS would provide a lot more security.

All times are GMT -5. The time now is 03:33 AM.