What are DSO modules?
"On modern Unix derivatives there exists a nifty mechanism usually called dynamic linking/loading of Dynamic Shared Objects (DSO) which provides a way to build a piece of program code in a special format for loading it at run-time into the address space of an executable program.
This loading can usually be done in two ways: Automatically by a system program
ld.so when an executable program is started, or manually
from within the executing program via a programmatic system interface to the
Unix loader through the system calls
In the first way the DSO's are usually called shared libraries or
DSO libraries and named
libfoo.so.1.2. They reside in a system directory (usually
/usr/lib/) and the link to the executable program is established
at build-time by specifying
-lfoo to the linker command. This
hard-codes library references into the executable program file so that at
start-time the Unix loader is able to locate
/usr/lib/, in paths hard-coded via linker-options like
-R or in paths configured via the environment variable
LD_LIBRARY_PATH. It then resolves any (yet unresolved) symbols in
the executable program which are available in the DSO.
Symbols in the executable program are usually not referenced by the DSO
(because it's a reusable library of general code) and hence no further
resolving has to be done. The executable program has no need to do anything on
its own to use the symbols from the DSO because the complete resolving is done
by the Unix loader. (In fact, the code to invoke
ld.so is part of
the run-time startup code which is linked into every executable program which
has been bound non-static.) The advantage of dynamic loading of common library
code is obvious: the library code needs to be stored only once, in a system
library like libc.so, saving disk space for every program.
In the second way the DSO's are usually called shared objects or
DSO files and can be named with an arbitrary extension (although the
canonical name is
foo.so). These files usually stay inside a
program-specific directory and there is no automatically established link to
the executable program where they are used. Instead the executable program
manually loads the DSO at run-time into its address space via
dlopen(). At this time no resolving of symbols from the DSO for
the executable program is done. Instead the Unix loader automatically resolves
any (yet unresolved) symbols in the DSO from the set of symbols exported by the
executable program and its already loaded DSO libraries (especially all symbols
from the ubiquitous
libc.so). This way the DSO gets knowledge of
the executable program's symbol set as if it had been statically linked with
it in the first place."
(Taken from http://httpd.apache.org/docs/dso.html)
mod_dso module is ProFTPD's module for handling the dynamic
loading of modules. This module is contained in the
file for ProFTPD 1.3.x, and is not compiled by default. Installation
instructions are discussed here.
The most current version of
mod_dso can be found in the
ProFTPD source distribution:
LoadFile directive is used to load any shared object
.so file extension), such as shared libraries. On some
platforms, it may be necessary to load all of the libraries needed by
a DSO module, using
LoadFile, prior to loading the module itself.
The path parameter must be the absolute path to the shared object to load.
# Load the zlib library LoadFile /usr/lib/libz.so
LoadModule directive is used to dynamically load a module
from the configuration file.
ModuleControlsACLs directive configures access lists of
users or groups who are allowed (or denied) the ability to
use the actions implemented by
mod_dso. The default
behavior is to deny everyone unless an ACL allowing access has been explicitly
If "allow" is used, then list, a comma-delimited list
of users or groups, can use the given actions; all
others are denied. If "deny" is used, then the list of
users or groups cannot use actions all others are
ModuleControlsACLs directives may be used to
configure ACLs for different control actions, and for both users and groups.
The actions provided by
mod_dso are "insmod"
"lsmod", and "rmmod".
# Allow only user root to load and unload modules, but allow everyone # to see which modules have been loaded ModuleControlsACLs insmod,rmmod allow user root ModuleControlsACLs lsmod allow user *
ModuleOrder directive can be used to explicitly set the
module order. Note: do not use this directive unless you know what
you are doing. It is very easy to configure a non-working server with
If you are going to use
ModuleOrder, make sure it is
the very first directive in your
# Make this one the very first things, if you're going to use it. ModuleOrder \ mod_core.c \ mod_cap.c \ mod_auth_unix.c \ mod_auth_pam.c \ mod_ls.c \ mod_log.c \ mod_site.c \ mod_xfer.c \ mod_auth.c \ mod_ifsession.c \ mod_auth_file.c
ModulePath directive is used to configure an alternative
directory from which
mod_dso will load DSO modules. By
mod_dso uses $prefix/
where $prefix is where you installed
The path parameter must be an absolute path.
insmod control action can be used to load a DSO module
into the running
A module cannot be loaded multiple times.
ftpdctl rmmod mod_test.c ftpdctl: 'mod_test.c' loaded
lsmod control action is used to display a list of all
ftpdctl lsmod ftpdctl: Loaded Modules: ftpdctl: mod_core.c ftpdctl: mod_xfer.c ftpdctl: mod_auth_unix.c ftpdctl: mod_auth_file.c ftpdctl: mod_auth.c ftpdctl: mod_ls.c ftpdctl: mod_log.c ftpdctl: mod_site.c ftpdctl: mod_dso.c ftpdctl: mod_ctrls.c ftpdctl: mod_auth_pam.c ftpdctl: mod_cap.c
rmmod control action can be used to unload a DSO module
from the running
proftpd daemon. Note that it is also
possible to "unload" one of the staticly-linked modules; this
does not remove that module from the process' memory space, but does remove
that module from the core engine, such that
act as if the module is not present.
ftpdctl rmmod mod_test.c ftpdctl: 'mod_test.c' unloaded
mod_dso's control actions are only available if your
proftpdhas been compiled with Controls support.
mod_dsomodule is distributed with ProFTPD. To enable use of DSO modules, use the
./configure --enable-dso make make installThis option causes
mod_dsoto be compiled into