Take the 2-minute tour ×

I have a fuzzy notion of what the term "ftp jailing" means, but when it comes to permissions and security, fuzzy is imprudent. What is it? How is it implemented? Is it mostly a capability of the ftp server, or does it emerge from how the underlying OS does permissions?

share|improve this question

7 Answers 7

up vote 3 down vote accepted

"Jailing" in ftp means locking the ftp session to a particular subset of the filesystem. Usually it is set so that if a particular user logs in, they can only ftp to their own directory space.

The ftp server will often have an option that, when a user is connected, to chroot the user, which means as far as that user is concerned, the root of the universe is some specific portion of the total available filesystem.

'vsftp' has a really clear explanation and how-to at vsftpd.

Some other examples include proftp and ftp on hp/ux.

share|improve this answer

It's a feature of the ftp server (for the most of them) for example with vsftpd you can "jail" users to their homedir by using configuration


The ftp server will not let the user to go below that directory.

User homedir: /home/ftp
User can access: /home/ftp, /home/ftp/pub
User can not access: /home, /etc, /, /root etc..
share|improve this answer

It can mean two things:

  • a (or all) user/login is restricted to their "home directory" as opposed to having a full view of the FTP hierarchy. This is typically implemented in software at the application level (e.g. FTP server).
  • the FTP processes are jailed in a chroot type of setup, as a security measure. This is pretty common for servers which allow anonymous access. In the old days, this was done via the chroot syscall, although I've a feeling there may be more modern ways to do this now on some OSes. Anyhow, this type of setup is a bit more tricky and far more OS dependent (even if simply using chroot).
share|improve this answer

FTP jailing means that the loggend in user sees his root directory as one that you define. He cannot go any higher up the tree, as the FTP client sees his dir as the root directory.

Say you have the following:


You set the root to /home/ben_linus/

He will see

share|improve this answer
Ben Linus :-) So, he doesn't see /home/jacob/ ? ;-) –  splattne Jun 12 '09 at 13:27
That would be correct. Only john_locke can see /home/jacob, as his jailed root is set to /home/. :) –  Dax Jun 13 '09 at 13:16

I don't see a reason why it should be OS dependent. Nothing keeps you from coding an FTP server that will return / for some random directory after using cd .. often enough without actually being in / on Unix or at the top level drive in Windows.

Regarding permissions it depends a lot on how you configure your FTP servers, some FTP servers can map from/to any user, that means you could configure an FTP server that need "normal" authentication but when writing the file to the OS on the host permissions will be mapped to a certain user you configured.

Some discussion about chroot (as well as a follow up link) can be found in the ProFTPd FAQ.

share|improve this answer

Here's how I do it in a Windows IIS environment. Figure it will help someone in the future.

  1. set up the local user accounts on the computer for each "user/client"
  2. In explorer setup the NTFS structure so that you have a "root" folder and inside that folder you have folders for each client/etc.
  3. Set up the NTFS rights, so that each user (you can use a group called FTP users, and add them all to that group) has "List" rights to the root folder. Then give them specific rights to each of their "home" folders (read/write/whatever).
  4. In IIS for the FTP site, create virtual directories named EXACTLY the same as the user accounts you created, and point each one to the right home folder. ie. virtual directory of BOBJONES points to d:\ftpsite\BOBJONES
  5. go back into explorer and create a new folder in the same folder as the ROOT folder and call it DEADEND
  6. give the FTP users list/read permissions to the DEADEND folder
  7. Back in IIS set the "root folder" for the FTP site to the DEADEND folder

That's it.

now when BOBJONES logs into the FTP site he is in the BOBJONES directory. If he gets wily and tries to do a cd .. to go up to the parent/root he'll get knocked into the DEADEND folder and won't see the list of everyone else's home folders, etc. (NOTE: he can get back to his home folder by typing cd BOBJONES still)

ONE FINAL NOTE: anybody that has a user ID but no virtual directory named the same will get defaulted to the root directory which has been changed to DEADEND.

share|improve this answer
I recently discovered that for Windows Server 2008 / IIS 7 there is a separate download FTP 7.5, which is much better than the old version. –  splattne Jun 12 '09 at 13:29
+1 for explaining how to do this in Windows land. –  steve.lippert Jun 12 '09 at 13:56
I'm torn. Part of me is happy I just installed filezilla, which made it easier and cleaner by the looks of it. Part of me wishes I'd known this when I was trying to make it work with IIS. Think I'm happy I have filezilla in the end. –  Kyle Hodgson Jun 12 '09 at 14:13
This proved to be most useful - cheers. –  Izzy Sep 21 '09 at 22:02

In the old days on UNIX systems, jailing users to a certain directory was cumbersome, error prone, and could lead to problems. You had to compile special static linked binaries for things like ls and cd and move them in to the jail, for instance. If your OS / software is requiring this - note to the wise, it's problematic. I much prefer newer FTP servers that don't require this approach.

On IIS, I find jailed FTP difficult to do - though there is one description for something close above, its not exactly as smooth. Kudos for doing that though, I've tried many times to find something like that. I use Filezilla on Windows instead, it has a rather elegant solution to the jails problem that works as expected. No security ramifications that I'm aware of, Filezilla seems to fix vulnerabilities quickly.

Modern UNIX FTP implementations seem to make jailing much easier, and probably much safer. The majority of the security concerns remaining; once you assume that you are OK to grant your user access to anything below the jail point, is the question of "is my vendor / FOSS software provider providing patches in a timely manner?"

share|improve this answer

Your Answer


