Does Dovecot's test authentication driver leak supplied credentials through process titles?
0 reputation · 28 Dec 2021, 01:29 UTC
0 reputation · 28 Dec 2021, 01:29 UTC
When validating an authentication integration locally, Dovecot's built-in test passdb allows testing without real production credentials. The passdb { driver = test } configuration and the doveadm auth test utility are documented for debugging, but it is uncertain whether the supplied username or password becomes visible outside the Dovecot process. On shared systems, a transient credential exposed in a process title or environment variable could be captured by other users.
The unresolved point is whether the test authentication path writes the username or password into the process title, environment, or log buffer in clear text, and whether that behavior is consistent across supported Dovecot releases. Administrators need to know if the test driver is safe to run on a multi-user test host without first scrubbing the command line.
Does doveadm auth test expose the supplied username or password in the process title or environment variables visible to ps? Is there a supported way to invoke the test passdb so that credential strings never appear in process listings? Which Dovecot versions have altered the handling of process titles for authentication commands?
35275 reputation · 28 Dec 2021, 09:57 UTC
Yes, doveadm auth test exposes the supplied username and password in the process title. Because the utility accepts credentials as direct command-line arguments, these strings are passed to the operating system's process table. On most Unix-like systems, any user on the host can view these credentials in clear text using tools such as ps, top, or by inspecting /proc/[pid]/cmdline.
The exposure does not occur because of a flaw in the test passdb driver itself, but rather due to how the shell and OS handle command-line arguments. When you execute a command like doveadm auth test user password, the shell passes these strings as argv to the kernel. The kernel stores this information in a memory area that is globally readable by default on many Linux distributions.
This behavior is consistent across Dovecot releases because it is a fundamental property of the doveadm CLI design. There is no internal mechanism within doveadm to "scrub" or mask the process title after the process has started, as the arguments are already visible to the system the moment the process is spawned.
To prevent credentials from appearing in process listings or shell history, avoid passing passwords as direct arguments. Use the following scoped methods for safer local validation:
/proc/[pid]/environ, they do not appear in a standard ps output.You can verify this exposure on your specific OS version with these commands:
# Terminal 1: Run the test (use a dummy password)
doveadm auth test testuser dummy-password
# Terminal 2: Check the process list immediately
ps aux | grep doveadm
If the password appears in the ps output, your environment is susceptible to this leak.
Missing Diagnostic: To provide a more specific alternative, please specify the exact version of Dovecot and the underlying OS distribution you are using.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.