Daemon to lock files in memory with mlock
memlockd [ -c config-file ] [ -d ] [ -f ] [ -u user ]
This manual page documents briefly the memlockd command.
It is used to lock system programs and config files in memory so that if a DOS attack is experienced then the chance of the sys-admin regaining control of the system in a reasonable amount of time (and therefore having a reasonable chance of discovering the cause of the problem) is significantly increased.
The -c option is used to specify the fully-qualified path name to a config file that lists the names of files to lock, if the config file is not specified then it will default to /etc/memlockd.cfg. In any situation where a config file is used a directory can be used instead, for a directory every file ending in ".cfg" will be processed.
The -d option specifies debugging mode, the program will not fork and will produce it's logging messages on stderr instead of via syslog.
The -f option specifies foreground (non-daemon) mode, the program will not fork but will still log normally.
The -u option specifies the name of a user to use for running ldd (for recursive operation). Note that locking shared objects that are writable by non-root is not safe, but using a different UID will reduce the risk.
The config file will contain a number of fully qualified names of files to lock in RAM. When locking shared objects and ELF binaries it is possible to prefix the file name with a + character to indicate that memlockd should recursively lock all shared objects that the program requires and all shared objects that those objects require. When a file not found error doesn't matter (EG you want a single config file to have the file names for multiple architectures or systems) you can prefix the file name with a ? character, in that case errors such as EPERM will still be logged.
If a line in the config file starts with a % character it will be taken as the name of a config file or directory to process. Currently only one level of recursion is accepted.
memlockd was written by Russell Coker <[email protected]>