There are several thousand blog posts about vsftp and allow_writeable_chroot=YES

The common error message:

Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

I solved the problem on my server.

But one question remains:

Why is it advisable to use allow_writeable_chroot=NO?

Up to now I only found nebulous arguments like "For security reasons".

What are these "security reasons"?

  • 2
    Where is the official documentation for allow_writeable_chroot?
    – guettli
    Dec 18, 2015 at 11:38
  • 1
    Nowhere : security.appspot.com/vsftpd.html but you may have an answer there : #vsftpd IRC channel at irc.freenode.net.
    – Froggiz
    Dec 18, 2015 at 11:46

2 Answers 2


If the FTP credentials of a user (even a virtual user) with a writeable chroot get compromised, the attacker might conceivably be able to perform a ROARING BEAST ATTACK. To summarise my rough understanding of this attack, it involves exploiting the fact that some C libraries (perhaps including ones used by the FTP server) will look for dynamic libraries that they depend on at hard-coded paths in /etc or other common locations. The attacker uploads evil versions of those dynamic libraries to the /etc within the chroot, then sends a command to the (running-as-root) FTP server that induces it to run some code that loads in that dynamic library from /etc. The attacker's evil code then runs as root. This escalates the attack from a mere compromise of the user's FTP folder to rooting the entire machine.

Having a non-writeable chroot renders this attack impossible (unless you, the sysadmin, have unwisely created writeable folders with names like /etc and /lib within your FTP users' chroot directories).

  • I like to switch the perspective and to look at the world through the eyes of a evil black hat hacker :-) Thank you for the link to the roaring beast attack. Lazy loading of libraries ... then loading from chroot ... nice.
    – guettli
    Sep 6, 2017 at 10:58
  • Why would vsfrpd load any libraries, evil or not from /etc within a chroot??? Jun 23, 2021 at 9:28
  • @AndrewSavinykh because once you've chrooted the /etc within the chroot just looks like /etc - that's the whole point of chrooting - and the standard mechanism for loading dynamic libraries looks for stuff in /etc and /lib. Or at least, that's my understanding of the linked post and of unix.stackexchange.com/a/22999/29001!
    – Mark Amery
    Jun 23, 2021 at 9:45

The main concern is that it makes dotfiles writable. Depending on your shell, the way login is set up, whether $HOME/.ssh is used, what other services are running and a few other things, this provides a lot more attack surface to abuse, mostly through manipulation of user environment variables. There isn't a comprehensive guide on what and why because that would require knowing the attacks before they happen.

Long story short, for usability, most distributions reference a user's home directory in one way or another and making it writable means those references could potentially be manipulated.

  • 1
    .ssh/authorized_keys is not (directly) inside $HOME. A readonly $HOME does not help for this file. And for .bashrc: if you are allowed to login into this $HOME, then you can set any environment variable you like interactively. I still don't get it.
    – guettli
    Dec 18, 2015 at 14:27

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.