Java Secure FTPd Server (jFTPd)

Configuration

On Microsoft Windows systems:

jFTPd can run standalone or as service. About running as a service, jFTPd has no built in mechanism to do that, but it was custom fit to run along with JVMI [commercial, available here: http://www.kcmultimedia.com/jvmi/ ]

On UNIXes (and flavours):

jFTPd runs standalone as root user (you need to create/update scripts to start it on the required run level every time the machine boots ).

If you decided to deploy jFTPd in other directories, you need to modify all the scripts with the new proper directory.

Adding users:

To add users, you have to modify the users.dat file. Usually it resides in jftpd's directory, but its location can be specified in the configuration file (more on this on the [Configuration File Specification]). There is no relation between the users.dat file and /etc/passwd (or other system files).

The format of users.dat file is this one:

username, password, [mask=default_mask_specification ,] home_dir1 = virtual_name1 [(mask1_for_dir)] [, home_dir2 = virtual_name2 [(mask2_for_dir)], ....]

Looks complicated, but lots of things are optional. Here are some examples:

# username with access to the directory /home/andrew

andrew, pass1234, /home/andrew = andrew

# username with access to directories /home/andrew and /data/exchange

andrew, pass1234, /home/andrew = andrew_home, /data/exchange = shared_space

Obs: when the user will login, he will see two virtual directories: andrew_home and shared_space.

The mask applies on Unix systems and its format is this one:

owner|group|rights[|<r|rw|w>]

After a file is successfully uploaded, a

chown owner:group file_name

is issued and a

chmod rights file_name

is issued too. This is needed because the user should be able to delete his/her files if connecting via SSH for example.

<r|rw|w> part is optional, and specifies if the user is able to only read ('r') the directory, or if it is able to only write it ('w' - for depositor access to a directory) or if he can both read and write the directory.

The default_mask_specification applies too all the directories specified for a user. It is needed if you want to give the same rights to all the directories the user is allowed to access.

However, each directory can have its own mask, and that overrides the default mask specified for the user account - this way you can fine tune the access to each directory.

None of the masks are required, because there are also defaults specified in the configuration file (useful for hosting providers, where the uploaded files must be owned by apache).

A full example line from the users.dat file is this one:

Configuring the network [and other] parameters.

There is another configuration file named java.properties. This file controls all aspects of jFTPd (including debug messages, welcome message, port, ip advertised to the FTP client in case of PASV connections, and so on).

The file format is

# comment line

property.name=property.value

…

Please check the bundled jftpd.properties file for an example on proper style.

Click here to see all parameters that can be specified in the configuration file. Most of them have defaults, and for a quick setup the bundled jftpd.properties file is enough.

Generating the SSL certificate.

jFTPd stores its certificate in a keystore file named jftpd_keystore. There is a sample command file to create the keystore:

keytool -genkey -alias jftpd -keyalg dsa -keystore jftpd_keystore

For now, there are two limitations:

- You must use 'aaaa11' as a password.

- jftpd_keystore must be in the same directory as the configuration file, there is no path entry for this file in the configuration file to specify the path to the

If you obtain a signed certificate, based on the generated one, you can import it in the keystore using the keytool.exe (works the same on Unix).

Tweaking the java.security file.

To enforce that users do not access to other parts of the file system (in case of bugs for example), jFTPd uses a java.security file which restricts what directories the java application (jFTPd) is able to run. This is imposed by JVM and not by the code - so it is an additional security mechanism.

The zip file contains a security file which is generic enough to allow further customizations to be made by the system administrator.

One thing needs to be mentioned about java.io.FilePermission [for more information about java.security file format, please check Sun's Default Policy Implementation and Policy File Syntax].

To give recursive permissions to a directory (meaning that the java application is able to access both the directory content and any subdirectories under, you need to add two lines for that directory in the security file:

permission java.io.FilePermission "/tmp", "read, write, delete, execute";

permission java.io.FilePermission "/tmp/-", "read, write, delete, execute";

one time for the directory itself and another one for all the directories found under ("/-" at the end of the filename).