vsFTPd and symbolic links
vsFTPd is probably the most secure FTP daemon that exists for *nix operating systems and that is shipped with a number of Linux distributions as the default FTP server. Given the fact that its purpose is offering an FTP daemon implementation with regards to security, there are some limitations.
One of these limitations includes the use of symbolic links. vsFTPd doesn’t allow browsing symbolic link targets as long as their target is outside the user’s chroot. Let’s try the following scenario (based on my router’s configuration):
- we have this folder: /tmp/harddisk/music
- we have the following folder for user: /tmp/harddisk/ftp_pvt/user
- we create a symbolic link inside user‘s folder to point to the music folder:
ln -s /tmp/harddisk/music /tmp/harddisk/ftp_pvt/user/music
It seems like everything is okay. As long as the permissions for the folder music grants access for the right users, everybody following that symbolic link on the system should be able to do whatever he/she is allowed. But when trying to access that folder (following the symbolic link) via vsFTPd, the user will get:
Status: Retrieving directory listing... Command: CWD /disc0_3/ftp_pvt/user/music Response: 550 Failed to change directory. Error: Failed to retrieve directory listing
So, what’s the solution besides the stupid one of copying the directory that you want to be accessed to a place where user has access? Simple. Mount! How? Well, like this:
- create a directory inside user‘s chroot:
- mount the folder you want user to access using the bind option:
mkdir /tmp/harddisk/ftp_pvt/user/music
mount --bind /tmp/harddisk/music /tmp/harddisk/ftp_pvt/user/music
Now you can properly give access to folders and files located outside of a user’s chroot without compromising security using vsFTPd. Any complaints?
You might also like:
11 Comments
Leave a comment
Recent Posts
Projects that I support
Recent Comments
nope said:
yeah that was my first thought too, but: mount: warning: seems to be mounted read-write. too bad, would have been just perfect. more»Klaus Deiss said:
Dear Radu, I tried it on Ubuntu 10.0.4.2 and 10.0.4.3 with different kernel versions (amd64 server 2.6.32 kernel). No... more»scompo said:
Nope.. Now it’s not working again.. This printer it’s a real pain in the butt.. The other hp printer I had... more»Dmitrij said:
Thank you Peter and Patrice. Could you please post the updated script? more»hd_flash_pains said:
didn’t work for me more»
Thank a lot!
You may also want to add mount –bind command into /etc/rc.local to make mounted directory available after a reboot
Consider “/realdata/dir /virtual/dir none default,bind 0 0″ in /etc/fstab to make the “mount -B” available on reboot as well (perhaps less obscure than “/etc/rc.local”). Note: don’t bother looking into hard links, since they will not link directories, and will not file systems.
you saved me. Thanks.
Thanks couldn’t work out what was wrong with sym links and vsftpd, good tip to put in rc.local also
[...] If you want the same functionality, you should use "mount –bind". Take a look at this howto for details [...]
Thanks! It worked like a charm!
Great… It’s work for me… Thank You.
this solves the symlink problem , but it opens up a potencial new one :
if one day you remove the vsftpd user and remove the content of user’s home folder without checking it first , you remove also the target of the mounted path – something you most probably didn’t want to do .
So make some warning somewhere you’ll see when you’ll be cleaning these users directories to watch out for this .
@torson : You can mount the directory in read only, this will prevent you to delete it.
yeah that was my first thought too, but:
mount: warning: seems to be mounted read-write.
too bad, would have been just perfect.