After upgrading vsftpd or vsftpd-ext you may be getting the following message when trying to log in.
500 OOPS: vsftpd: refusing to run with writable root inside chroot ()
This is due to the following update:
- Add stronger checks for the configuration error of running with a writeable
root directory inside a chroot(). This may bite people who carelessly turned
on chroot_local_user but such is life.
The problem is that your users root directory is writable, which isn’t allowed when using chroot restrictions in the new update.
To fix this you must either remove write permissions on the users root directory with the following command, replacing the directory with your users root:
chmod a-w /home/user
Or you can work around this security check by adding either of the two below into your configuration file.
For the standard vsFTPd build (vsftpd):
allow_writeable_chroot=YES
For the extended vsFTPd build (vsftpd-ext):
allow_writable_chroot=YES
Removing the write permission on the root isn’t a perfect solution as doing this can cause a few problems with things that need to write to the root directory, such as the bash history file or some graphical environments.
Dmitriy has suggested 3 ways to also overcome this problem, be sure to check them out.
This solution will then prevent user from uploading any files since they won’t have write access to the directory. How do you solve if the purpose of the FTP access is to allow uploading of files?
It will only prevent uploading files to the users root directory, not any sub-directories. I didn’t have this issue as I don’t write to the root directory but instead have various sub-directories for each website.
I’m going to assume that this is the only way of working around this unless you compile from source and remove that part of the update yourself.
Thanks. Seems strange to require that a person CD into a subdirectory in order to upload files. I tried setting local_root to something other than the user’s home directory — but that still creates the same error — because after the FTP connection is established it does a chroot() to that new directory. Seems like vsftpd works hard to require a person to explicitly CD into a subdirectory before uploading files. Is this some new FTP security best practice? Or just a vsftpd oddity? I haven’t tried it, but I’m guessing “virtual users” will have the same issue…
The official reason was for security: “disallow login with writable root directory because of possible glibc vulnerabilities”.
I was looking on the Arch linux forums and I came across a workaround, I’m not sure if this exists on other distributions though:
https://bbs.archlinux.org/viewtopic.php?pid=1038842#p1038842
I tested this and sure it works.
But if your users are also allowed to SSH in or otherwise use tools that write files to the root of the users home directory that will fail.
Like updating history of bash/vi commands etc, like these files:
.bash_history
.bash_logout
.bash_profile
.bashrc
.viminfo
The only way to get around it currently is to compile vsftpd yourself, unless somebody can come up with a better option because I can’t think of one at the moment.
Hello, put up to config file /etc/vsftpd/vsftpd.conf option:
allow_writable_root=YES
you can choose one of 3 ways:
1. Define option local_root= in configuration file. must by /home or other path to directory with users folders.
In this way vsftpd chrooting to /home directory.
2. Define option passwd_chroot_enable=yes in configuration file and change in /etc/passwd file user home directory from «/home/user» to «/home/./user» (w/o quotes).
In this way vsftpd chrooting to /home directory.
3. Download sources of vsftpd-ext, compile and overwrite exist vsftpd binaries or take it from repositories and add to configuration file option allow_writeable_root=yes.
Little typo in point 3.
allow_writable_root=yes
should be:
allow_writeable_root=yes
This missing e got me mad…
Thanks Dmitriy, I’ve added a comment in the post about your solutions.
Thanks!
Very sad behavior of the new vsftpd version, makes it basically unusable because /home/$user directories without write rights for the user are a joke. Defeats the entire purpose of allowing ftp access to the home directories :-(
In freebsd from ports 3th metod : vsftpd-ext with allow_writable_root=yes not working !
Are you using the latest vsftpd-ext?
For me it works (vsFTPd version 2.3.5+ (ext.1))).
yes, 2.3.5.1
vsftpd started with inetd:
ftp stream tcp nowait root /usr/local/libexec/vsftpd vsftpd
config:
anonymous_enable=NO
local_enable=YES
write_enable=YES
listen_port=21
local_umask=022
anon_upload_enable=NO
anon_mkdir_write_enable=NO
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
hide_file={/mail}.
secure_chroot_dir=/usr/local/share/vsftpd/empty
max_clients=200
max_per_ip=100
chroot_local_user=YES
text_userdb_names=YES
force_dot_files=YES
listen_address=xxx.xxx.xxx.xxx (my ip adress)
allow_writable_root=YES
You could try emailing Dmitriy(the chap that runs the project I believe) for help as I have no idea what could be wrong there. His Email is at the bottom of this page: http://vsftpd.devnet.ru/
Oh. I agree with Gerald, very sad behaviour, I cant configure in proper way my ftp server, it`s terrible.
mikel; can’t you add this directive to your conf instead of using “allow_writeable_root”
local_root=/home
Or one of the other options posted by dmitriy?
The only thing you have to do is treat users home as users home and put everything inside a dedicate directory, like the public_html used to accomplish.
BTW the FreeBSD works like a charm.
Cheers
I agree with Massimo, the easiest way to deal with this imho is to move everything into a writable subdir, then chmod a-w the root dir. (can be a bit of a pain in the ass for loads of virtual users, but works)
the option chmod a-w /home/user doesn’t work in an graphical environment, since it will prevent system from loading/writing some crucial files.
Option 1 worked for me, thanks
One tip for anyone having trouble with this:
At some point during my fooling around, my system (Ubuntu 12.04) stopped looking at /etc/vsftpd.conf–any changes I made were COMPLETELY ignored.
If that happens to you, copy your config file over to /etc/vsftpd/vsftpd.conf (you’ll probably need to make the directory).
chmod a-w /usr/local/share/vsftpd/empty
Dmitriy’s #1` suggestion worked perfectly.
I added the line local_root=/home/wally/Public to the vsftpd.conf file and I ‘connect to server’ in Nautilus using that address location.
Once there, I bookmark that location and it is not only always there in Nautilus, but also directly from the Unity launcher (using Ubuntu 12.4). by right clicking the file icon. This connects to the Public folder that is installed by default by Ubuntu, but you could point to any other subfolder just as easily… jut not to the home folder itself. Really quick and easy.
in /etc/vsftpd.chroot_list add user to chroot,
add “/usr/sbin/nologin” to /etc/shells & add :/usr/sbin/nologin in /etc/passwd
And why are such restrictions added?
The official reason is “Disallow login with writable root directory because of possible glibc vulnerabilities”
I have a ton of business critical EDI transactions between my customers, and vendors and customers of my customers, all going to and from a bunch of different 24/7 production application servers, The remote people aren’t even my customers but customers of my customes and vendors of my costomers. These countless oddball custom automated procedures have been accumulating for years, and NOW all of the sudden they all break when I update vsftpd or update a whole server, or just install a new server and try to move customers onto it. It’s completely impractical to find all the people on the remote sides and get them to change their scripts and programs to change the paths to use subdirectories, let alone that we’d have to update countless scripts and programs on our side to match.
Out here in the real world this wonderful thoughtful caring change basically means I have to TURN OFF CHROOT on a bunch of publicly accessible servers…
Anyways, thanks for the pointer to the -ext fork. Since my boxes are all opensuse and since I already maintain several other special packages in an opensuse build service project, at least I can relatively easily package up that -ext fork and get it distributed and installed and turn chroot back on.
Guys check out this link…
http://serverfault.com/questions/384439/ubuntu-12-04-howto-downgrade-vsftpd/390887#390887
click on the “pool” hyperlink to download the earlier versions of vsftpd…
This works a treat having spent all day invesitigating this problem with 12.04 and the latest devil version of vsftpd 2.3.5!!! Just mysql to sort out now!!! :D
Good News!
Stock vsftpd 3.0.0 includes a new config option:
allow_writeable_chroot=YES
I was in the process of extracting just that option out of the full -ext patches, and discovered that particular feature is already in stock 3.0.0 with a slightly different name than in -ext.
dev1:oh7:~/src/vsftpd-3.0.0 # grep allow_writeable_chroot *
Changelog:- Add new config setting “allow_writeable_chroot” to help people in a bit of
parseconf.c: { “allow_writeable_chroot”, &tunable_allow_writeable_chroot },
tunables.c:int tunable_allow_writeable_chroot;
tunables.c: tunable_allow_writeable_chroot = 0;
tunables.h:extern int tunable_allow_writeable_chroot; /* Allow misconfiguration */
twoprocess.c: if (!was_anon && tunable_allow_writeable_chroot)
dev1:oh7:~/src/vsftpd-3.0.0 #
One thing: I noticed that the 3.0.0 source has a writeable chroot change in twoprocess.c but not in oneprocess.c, while the 2.3.5-ext source has writable chroot changes in both oneprocess.c and twoprocess.c. I have verified that the new option works in the default two-process mode on stock 3.0.0. I have not verified that it works in one-process mode.
–
bkw
Thanks Brian, I’ve updated my post to reflect this new config option, hopefully it’ll give people a few more options to choose from!
I was also trying for hours to setup my 12.04 server access to allow me to upload pages via ftp on the LAN. After clearing the 530 error, I was stuck on the error this thread is addressing. Solution: follow the suggestion #1 of Dmitriy and Massimo. Finally the answer was simple. Place the ftp home directory in a directory which you have removed write permission for. Point to that directory in vsftpd.confi.
@Brian K. White
I try running vsftpd version 3.0 with allow_writable_chroot=YES and it won’t start. Same behavior with the previous version 2.3.5
Try using vsftpd-ext instead.
>>This may bite people who carelessly turned on chroot_local_user but such is life.
The above sentence nicely sums up the sheer arrogance of open-source community who obviously believes that if something they produce is free they don’t have any liability when they introduce a breaking change and that we should not assume that next version will work as it did or at all.
Whoever thought of that change is a shortsighted moron who didn’t think about all possilbe user scenarios out there.
People posting before me have already commented that this will break even standard Linux use (desktop/shell) so I won’t comment on that further.
In my case, I have a NAS box at home running Samba and FTP. I do not use my own user home directory in classical Linux way — it exists solely for Samba and FTP. It is completely normal to be able to write to my own root directory. If I can’t write into it, then I cannot create folders. I don’t want anyone forcing me to change my folder hierarchy and have one redundant level added to please someone’s security concerns.
If there really is a glibc vulnerability which is a reason for this change, why not fix that instead???
Hi!
I’m trying to compile vsftpd-ext but i can’t:
/usr/bin/ld: cannot find -lcap
/usr/bin/ld: cannot find -lpam
/usr/bin/ld: cannot find -lwrap
in Ubuntu server 12.04
Any ideas?
Thanks.
You’re missing some libraries/packages. A quick Google turned up this thread which you may need to translate:
http://forum.ubuntuusers.de/post/4552752/
I installed a new ubuntu 12.04 box for our customers transfering their data per ftp to our service.
At first vsftpd answered any ftp-login with “530 Login incorrect.” after googling and an annoying “apt-get remove vsftpd ; rm /etc/pam.d/vsftpd ; apt-get install vsftpd” a login was possible but we were locked out by “500 OOPS: vsftpd: refusing to run with writable root inside chroot()”
For me Dmitriys solution #2 workes perfect.
I added the option passwd_chroot_enable=YES and changed every users home directory from «/home/user» to «/home/./user» (w/o quotes) in /etc/passwd. “vi +’:1,$ s/home/home\/.’ /etc/passwd”
In this way vsftpd workes as usual.
But I do not understand what is wrong in using ftp this way – creating users without a shell in etc/passwd and chrooting them to their own home directory without a subfolder, because ftp is the only thing they can do. Maybe someone can give me a hint what I have done wrong using ftp in that way for more than a decade. So I hopefully can set up my ftp boxes accurate.
comment this lines, and working,
#chown_uploads=YES
#chown_username=whoever
the first option presented by Dmitriy works, but can i hide the other users folders, since if i have more than one user and set local_root=/home, any user will be able to see and browse the others users home folder?
or can i set the local_root (or any other option) using environment variables? so i can restrict users to a folder inside they home dir? for instance i would like to set local_root=$HOME/ftp and have the restricted there…
hope i made myself clear…
The solutions either don’t work (i.e. allow_writable_chroot=YES) or are unacceptable.
allow_writeable_root instead of allow_writable_chroot
Could not get allow_writeable_chroot or use Dmitry’s suggestion of changing the chroot in the vsftpd.conf .
What worked was disabling write access to the user’s home directory, and adding a folder within (similar to what Hannes has done).
sudo adduser test
##Restrict Shell Access
sudo usermod test -s /usr/sbin/nologin
##Add to ftp allowed list
sudo nano /etc/vsftpd.userlist
##Remove write access to home directory
sudo chmod u-w /home/test
##Make directory “inside” home directory
sudo mkdir /home/test/inside
##Give test ownership of directory
sudo chown test /home/test/inside
## Change group to test
sudo chgrp test /home/test/inside
I can only support what Igor Levicki said, the only who is acting “carelessly” here is the author of vsftpd:
A) Introducing breaking changes into a minor software update 2.3.5 is a very bad idea. My vsftpd server neither understands allow_writeable_root, nor allow_writable_root, nor allow_writeable_chroot, nor allow_writable_chroot and that I have to patch and recompile vsftpd to get it working again is supposed to be a joke.
B) Until today there has been given no justification for this breaking change, except dubious claims about a supposed vulnerability in libc. Please provide some information about this vulnerability and example code how it can be exploited.
Just a note that this issue causes what appear to be ssl problems when you have ssl enabled in vsftpd. An upgrade from opensuse 12.1 to 12.2 caused this problem for me but was hidden behind an ssl_read: wrong version number error when using lftp. To find out that this was the real issue I had to first set enable_ssl=No. After that I got the error above and google led me here. The allow_writeable_chroot=Yes fixed my issues.
My solution… rolling back to 2.0.5. Maybe I’ll look at upgrading again once the author pulls his head outta his ass, thanks.
For me (FreeBSD 9.0 x64) it works with this vsftpd.conf
Thank Brian K. White; Dimitiy…and al of you
For those of you running Ubuntu 12.04, I have created a vsftpd 2.3.5 PPA that backports the allow_writeable_chroot config option from vsftpd 3 to the existing Ubuntu package. To use it:
@Mark
I wanted to say let me know where I can send you a beer! I mean that. I owe you one.
After spending hours on this b.s. problem I finally found your solution and so far it’s testing perfectly and I am compiling a post about it. I encountered this b.s. in setting up a new Rackspace Cloud LEMP box: http://noconformity.com/blog/2013/01/09/rackspace-cloud-setup-ubuntu-12-04-lemp-server/
I hope you have a great start to the year.
@chrishough
Thanks Mark! This is perfect for 12.04.1 LTS
Mark, you’re the man.
This was the only solution I found to work for Ubuntu 12.04.
Thanks very much
You are wonderful Mark! Thank you, I’ve been attempting to solve this problem for ages!
thankyou Mark!
you saved me!
Cappo
Mark,
Many many thanks. You saved my life.
Mark, your solution seems good to me.
I have vsftpd already installed with all the configuration files set up for virtual users. Can you advise as to whether doing another install would lose all my settings.
I don’t know for sure as I’ve only done fresh installs with it. It’s the same as the regular Ubuntu package though, so it should ask you if you want to replace your config files during the update. If you’re unsure, you can always copy them somewhere before you update.
Mark, that works great. Many thanks.
The config files were left intact, and when I looked at it properly again there was only 2.
I am using this on my own little web server, but is is set up the same as the one I did at work before retirement. I have always had the ftp user going to the root of his account, as that is where I point Apache to. I am afraid that I cannot quite see the logic in the change that was made to vsftpd. Perhaps I have been doing it wrong for years.
Mark, You sir, deserve an internet.
Thanks a bunch.
Mark, you saved our lives!
# /usr/local/etc/rc.d/vsftpd restart
vsftpd not running?
Starting vsftpd.
500 OOPS: unrecognised variable in config file: allow_writable_chroot
/usr/local/etc/rc.d/vsftpd: WARNING: failed to start vsftpd
pkg_info | grep ftp
vsftpd-ext-2.3.5.1_1 A FTP daemon that aims to be “very secure”. Extended build
Have you given allow_writeable_chroot a go?
I could only get round this by upgrading to the latest deb package found here
http://us.archive.ubuntu.com/ubuntu/pool/main/v/vsftpd/
Which supports the allow_writeable_chroot=YES flag
Another solution is disabling SELinux this should work and make vsftpd work as usual, none of the solutions in this page worked for me. I am using a CentOS 6.4.
If you know what you are doing by disabling SELinux then there are no worries, this is how:
vim /etc/selinux/config
SELINUX=disabled
SETLOCALDEFS=0
SELinux turned off for current session
setenforce 0
Hope this helps someone. Regards.
Mark, you saved my morning! Thanks!
This whole article + all comments saved not only my morning, but the whole day!
>subscribed<
Great. I just did as you’ve said, changed the authority mode, and, and it works. Thank you.