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
If you are developing a module for wider distribution with
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.
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.
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:
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:
http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense http://www.gnu.org/licenses/gpl-faq.html#GPLAndPluginsDue 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
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.
Here are some recommended sources for further reading on secure programming and practices to keep in mind.