Run saslauthd Safely with a Local Authentication Backend

You will finish with a small, testable saslauthd setup using the local getpwent authentication mechanism, a private runtime directory and a socket check. The examples match saslauthd 2.1.28, installed here from sasl2-bin version 2.1.28+dfsg1-5ubuntu3.1. Your package version may expose a different set of mechanisms.

Allow about 20 minutes, plus time to adapt the service account and runtime path to your distribution. You need a Linux shell, the sasl2-bin package, a local test account, and permission to start a service. This guide does not change a real user's password or configure an application to send credentials.

1. Confirm the installed build

Start with read-only checks. These commands do not need elevated privileges:

$ saslauthd -v
saslauthd 2.1.28
authentication mechanisms: sasldb getpwent kerberos5 pam rimap shadow ldap
$ dpkg-query -W -f='${Package} ${Version}\n' sasl2-bin
sasl2-bin 2.1.28+dfsg1-5ubuntu3.1

The -a option is mandatory. Choose one mechanism that is actually listed by your build. This guide uses getpwent, which normally checks the local password database through the system's getpwent library function. It is not a universal promise that every name in /etc/passwd can authenticate: the system's account and password configuration still decides what the library sees.

2. Choose a runtime directory

saslauthd listens through a Unix socket below the directory passed to -m. The manual says that path must be absolute, must not end in /mux, and the directory must already exist. Its documented default is /var/state/saslauthd, although a build-time choice can change that default. Use an explicit path so the service and the client have the same contract.

First see whether your package already provides a service account and directory:

$ getent passwd saslauth
saslauth:x:...:...:...:/var/lib/saslauth:/usr/sbin/nologin
$ ls -ld /run/saslauthd /var/run/saslauthd /var/state/saslauthd 2>/dev/null

Output is host-specific. If your distribution has a packaged service unit, inspect it rather than creating a competing manual instance:

$ systemctl cat saslauthd.service

If the unit is already the source of truth, use its -m value and skip to step 4. If you are preparing a standalone test, choose /run/saslauthd and create it as root:

# install -d -o root -g saslauth -m 0750 /run/saslauthd
$ stat -c '%U:%G %a %n' /run/saslauthd
root:saslauth 750 /run/saslauthd

The exact group name may differ. Substitute the account used by your service. A runtime directory under /run is temporary and normally needs to be recreated at boot; a systemd unit or tmpfiles rule should own that lifecycle in a persistent deployment.

3. Start a foreground smoke test

Run a temporary foreground instance before enabling anything. This is the first state-changing step and may create a socket and a lock file, but it does not edit authentication databases:

# saslauthd -a getpwent -m /run/saslauthd -d

The -d option enables debugging. Leave this terminal open while you inspect the process. The daemon normally logs through syslogd using the LOG_AUTH facility; debug output may also appear in the foreground terminal depending on the build.

In a second terminal, check that the process and socket exist:

$ pgrep -a saslauthd
$ find /run/saslauthd -maxdepth 1 -type s -ls
$ ls -l /run/saslauthd/mux

The socket is normally named mux below the directory supplied to -m. Do not pass /run/saslauthd/mux to -m; pass only /run/saslauthd. If the socket is missing, read the debug message and check the directory owner, group and mode before changing any privilege.

4. Decide how the daemon should run

Protected mechanisms such as shadow need access to protected authentication data and must run as root according to the manual. For other mechanisms, the documented recommendation is an unprivileged saslauth:saslauth daemon, with a runtime directory owned by root and that service group. Follow the service account and unit supplied by your distribution instead of inventing a new one.

With systemd, a local drop-in can set the service identity. This changes how the service runs, so make a backup of the existing unit configuration and schedule a maintenance window:

# install -d /etc/systemd/system/saslauthd.service.d
# sh -c 'printf "%s\n" "[Service]" "User=saslauth" "Group=saslauth" > /etc/systemd/system/saslauthd.service.d/user.conf'
# systemctl daemon-reload
# systemctl restart saslauthd.service
# systemctl status --no-pager saslauthd.service

Do not apply this drop-in blindly if the packaged unit deliberately uses another account or has a stronger sandbox. Undo it by removing the drop-in and reloading systemd:

# rm /etc/systemd/system/saslauthd.service.d/user.conf
# systemctl daemon-reload
# systemctl restart saslauthd.service

Removing that file is deliberate and reversible, but restarting the service interrupts authentication requests. Confirm the service's existing options before making the change.

5. Set worker and cache behaviour deliberately

The default is five worker processes. Use -n when you have a measured reason to change it. A value of zero makes saslauthd fork one process per connection, which the manual describes as a way to work around leaks in some deployments; it also removes a useful bound on process creation, so do not use it as a casual performance setting.

Credential caching is off unless you add -c. The cache lifetime can be set with -t, in seconds. Caching can reduce backend work, but it also extends the period for which a successful authentication result remains usable. Treat -c and any cache timeout as security-sensitive policy, not harmless tuning. If you enable it, document the timeout and test the expected behaviour after a password change.

The -r option combines a login and realm as login@realm. That can distinguish domain-specific users for mechanisms that do not otherwise use the realm, but it can also change the identity passed to a backend. Leave it out until the client and backend contract explicitly requires it.

6. Diagnose failures without guessing

Use the following order when a client cannot authenticate:

1. Confirm the daemon's mechanism with pgrep -a saslauthd or the service unit.
2. Confirm that the configured -m directory is absolute, exists, and contains the mux socket.
3. Check service logs through your system's journal or syslog for the LOG_AUTH facility.
4. Check that the daemon account can read whatever backend data the selected mechanism requires.
5. Only then inspect the client configuration, including its socket path and realm handling.

A missing socket points to startup, path, ownership or lifecycle trouble. A present socket with rejected credentials points further into the selected authentication mechanism. Do not switch to root merely because the client reports a generic authentication failure. That can hide a permissions error and gives the daemon more authority than it needs.