ProFTPD Developer's Guide: Module Development

ProFTPD Version 1.2

Table of Contents

Module Development
As with any software development, there are certain things to watch out for when building a module. There are also other things to consider as part of the development process, such as configure scripts and documentation.

If you are developing a module for wider distribution with proftpd, please keep in mind the overall design philosophy: no use of system(2) or the exec family of system calls. Helper applications to accompany the module are acceptable; the server (and modules) should simply not invoke any code outside of its control.

Also, respect the normal filesystem permissions. proftpd has always honored the normal Unix permissions, and may provide access controls in addition to those of the filesystem, but do not override them. This only leads to trouble.

No modules or patches will be accepted into the ProFTPD source without documentation. Modules submitted without documents on what they do, on how to properly use any configuration directives the module might define, or on how to install and use the module, are next to useless by the ProFTPD community.

Patches without descriptions of what they are fixing, and why, force developers to read the code of the patch in order to decipher the purpose; the author of the patch has the best insight into the patch's purpose.

Common tasks
As you develop your module, you will find that there are some routines and operations needed that will have inevitably been done before, either in other modules, or in the core code itself. These pages describe some of the common tasks you can expect to encounter, and how they can be done:

Here are some other tips to keep in mind as you work on your module.

For the most part, this is easy -- GPL. However, when working with third-party libraries or code, be sure to include the necessary copyrights and licensing information as required by the use of those files. Some licensing issues to keep in mind are mentioned here:
Due to the nature of proftpd's module interface, third-party modules are considered part of the main binary, and thus by definition fall under the GPL (or GPL-compatible licenses), unless explicitly excluded (the OpenSSL code is excluded this way).

If developing modules that rely on cryptographic code, please be cognizant of any governmental laws or restrictions on the cryptographic code in use, in its licensing and distribution.

Always, always, ALWAYS check, verify, and sanitize user input, be it from configuration files such as .ftpaccess, from the configuration directive arguments for your modules, from any FTP commands you've created, etc etc. If you're going to open and write a file with root privileges, check to see if the file exists first. If it does, check whether it is a symlink, has data, whatever. Do not blindly write to a file name, unless you are absolutely certain of the conditions of the directory and file to which you are writing.

Secure Practices
Here are some recommended sources for further reading on secure programming and practices to keep in mind.

Table of Contents

Author: $Author: castaglia $
Last Updated: $Date: 2003/07/23 04:57:07 $

© Copyright 2000-2003 TJ Saunders
All Rights Reserved