Running the Directory Server as a Non-Root User

Like many network daemons, the Sun Java System directory server has a setuid capability that allows it to be started as a root user but then drop privileges to run as a user with fewer capabilities. The OpenDS directory server does not currently include this capability (and it would require native code to implement, which is not desirable). However, you can install, start, and run the directory server as a non-root user. Note that the information in this section applies primarily to UNIX-based platforms, because Windows systems do not historically place as many restrictions on non-administrative users.

Reasons for Running the Server as a Non-Root User

In many cases, running the directory server as a non-root user from the start is a more attractive option and provides greater functionality than the setuid equivalent. Running the server as a non-root user means that administrators do not need root access to the system, which is often desirable from an operational perspective. In addition, more administrative actions can be performed with the directory server online, because the server can do things that might not have been available after it had dropped root privileges.

The primary reason that directory servers are typically started and/or run as root users is so that they can listen on a privileged port (namely, ports between 1 and 1024). The standard port for LDAP communication is port 389, and the standard port for LDAPS is 636. On most UNIX-based systems only root users are able to create processes that listen on these ports. There can be other reasons for starting as a root user (for example, the ability to use a larger number of file descriptors), but it is generally easier to configure around these other limitations.

Although the standard LDAP and LDAPS ports are 389 and 636, the directory server is not required to run on those ports. In some environments, it is common to run the directory server on ports above 1024 (such as 1389 and 1636) so that it is not necessary to be root to start it. Virtually all LDAP-enabled clients provide the ability to specify the port on which the server is listening. As long as the clients know what port the server is using, any value is allowed. For information about configuring the listen port, see Configuring the LDAP Connection Handler.

How to Run as a Non-Root User on the Standard LDAP Ports

If clients expect the server to be listening on port 389 or 636, other options are still available. The best option, available on Solaris 10, is to use the process rights management subsystem (also called least privilege). The privileges subsystem in Solaris makes it possible to give non-root users and roles capabilities normally available only to the root user (much like the Privilege Subsystem allows within the directory server). In particular, the net_privaddr privilege controls which users can bind to privileged ports If this privilege is granted to a non-root user, that user can bind to privileged ports. To configure a user with this privilege, run the following command, as the root user:

# usermod -K defaultpriv=basic,net_privaddr,sys_resource,-proc_info,-file_link_any \
  opends

This command configures the opends user so that it starts with the basic privilege set (which is what non-root users have by default). The command then adds the net_privaddr and sys_resource privileges, which allow the user to increase the number of file descriptors available, among other things. The command removes the proc_info privilege (which allows the user to see processes owned by other users) and the file_link_any privilege (which allows the user to create hard links to files that they do not own). After running this command, the opends user is able to start the directory server listening on a privileged port.

Even on systems without a capability like least privilege, it is possible to expose the directory server on a privileged port such as 389 or 636 without requiring root privileges to be able to start it. One possibility would be to run the server on an unprivileged port and use a directory proxy server listening on the privileged port to forward communication to the directory server on an unprivileged port. It is also possible to use network hardware to achieve the same purpose or to use firewall rules on the same system. For example, on Linux systems the following commands can be used to redirect traffic targeting port 389 to port 1389:

# iptables --append PREROUTING --table nat --protocol tcp --dport 389 \
  --jump REDIRECT --to-port 1389
# iptables -t nat -A OUTPUT -p tcp --dport 389 -j DNAT --to :1389