List Cyrus SASL Database Users Safely with sasldblistusers2

sasldblistusers2 lists the users stored in a Cyrus SASL password database, so you can check which file you are reading before you trust it. This is a read-only guide: sasldblistusers2 lists entries but does not create, change or delete them.

Allow about ten minutes. You need a shell, the sasl2-bin package, and read access to the SASL database. The examples use the installed sasl2-bin version 2.1.28+dfsg1-5ubuntu3.1, with libsasl2 version 2.1.28. Package versions and database backends can differ on another host.

1. Confirm the command and library version

Start by checking which executable will run and asking it for its library version:

$ command -v sasldblistusers2
/usr/sbin/sasldblistusers2
$ sasldblistusers2 -v
This product includes software developed by Computing Services
at Carnegie Mellon University (http://www.cmu.edu/computing/).

Built against SASL API version 2.1.28
LibSasl version 2.1.28 by "Cyrus SASL"

The version option prints information and exits. It does not inspect the database. The exact attribution text can vary between builds, but the API and library versions are the useful checkpoint.

Checkpoint: You have confirmed that the command is installed and recorded the version before interpreting its output.

2. List the default SASL database

Run the command without options:

$ sasldblistusers2

The command reads the SASL password database, usually /etc/sasldb2, and prints the users stored there. A successful listing may therefore produce one line per SASL database entry, while an empty database may produce no user lines. The manual does not promise a fixed example line, so do not build a parser around a particular display format.

This is a narrower view than the system account database. It does not list users from /etc/passwd, /etc/shadow, PAM or another authentication service. A person who can log in through one of those systems may not appear here, and a SASL database entry does not by itself prove that any particular service uses it.

3. Read a specific database file

Use -f when you need to inspect a database other than the default. Substitute a real path that you have been authorised to read:

$ sasldblistusers2 -f /path/to/sasldb2

Use an explicit path when checking a staging copy, troubleshooting a service with a non-standard layout, or comparing two known database files. Check the path before running the command:

$ ls -l /path/to/sasldb2
$ sasldblistusers2 -f /path/to/sasldb2

If the file is missing, unreadable or not a compatible SASL database, the command may report listusers failed. That message identifies a read problem, not an empty user list. Fix the path or permissions, then rerun the same explicit command. Do not create a replacement database merely to make the listing command produce output.

4. Handle permissions without changing the database

The default database is commonly under /etc, so an ordinary account may not be able to read it. First run the command normally. If access is denied and your operating procedure permits it, repeat only the read operation with elevated privileges:

$ sudo sasldblistusers2 -f /etc/sasldb2

sudo is not a general prerequisite and it does not enable SASL or repair the file. It only changes the identity used for this read. Treat the database contents as sensitive authentication data: avoid pasting the output into tickets or shell transcripts, and do not grant broad read permission just to make an audit easier.

For a non-default file, verify its ownership and mode first:

$ stat -c '%A %U:%G %n' /path/to/sasldb2
$ sudo sasldblistusers2 -f /path/to/sasldb2

5. Keep listing separate from account changes

sasldblistusers2 has only two documented options here: -f file selects the database and -v prints the libsasl2 version. It has no option for adding, deleting or resetting users. Do not guess an edit flag from another tool's syntax. User creation and password changes belong to saslpasswd2, which should be reviewed separately before use because changing the shared authentication database can disrupt services.

Do not treat a successful listing as proof that an application is using this file. Cyrus SASL supports configurable database locations, and an application can have its own SASL configuration. Confirm the target service's configuration and authentication method before concluding that a listed account can authenticate there.

6. Diagnose the common traps

• No users printed: distinguish an empty database from a failed read. Check the command's diagnostic output, the selected path and its permissions.
• Unexpected users: verify that you did not read the default database when the service uses another file. Repeat with -f and an explicit path.
• System account missing: this tool is not a general Linux account inventory. Check the service's configured authentication backend instead.
• Different output on another host: record the package and libsasl2 versions first. The installed build, database backend and file contents all affect what you can observe.

Done means

• You confirmed the executable and recorded the libsasl2 version with sasldblistusers2 -v.
• You listed the intended database, using -f when the path was not the default.
• You distinguished SASL database entries from system, PAM and shadow accounts.
• You used elevated privileges only for an authorised read and made no database changes.