Dovecot wants to run the show

[miket]

I've been following the Complete Virtual Mail Server guide on the Gentoo Wiki. I've had to figure my way around several papercuts, but now I've reached one where I'm looking for suggestions as to which way to proceed.

Early in the process comes the instruction to set up Postfixadmin to manage a database that Postfix can query. That database contains a password column. Great, I thought! When yet-to-be configured components need to authenticate users, this is where they'd come.

Ah, but no. It's Dovecot that rules the show. That password column does store a password hash, but it follows Dovecot rules. It sure seemed bizarre to me that Dovecot would query the database for the password hash, extract the name of the hash function and salt from that, and do its own checking for the hash. Fair enough that IMAP clients, including Roundcube, would authenticate with Dovecot and not the database, but this made for an odd situation: when I used the configuration the guide indicated for setting up Dovecot's authentication mechanism, Postfixadmin could not generate password hashes that Dovecot would accept. This also meant that I could not set up Roundcube's plugin to let users change their own passwords.

The thing that let me go on with testing Dovecot's login (and further steps like the Let's Encrypt certificates, Roundcube, SMTP authentication) was to generate a hash by hand using doveadm so I could update the password column.

Now to make it work without manual intervention. I tried setting the 'encrypt' key in Postfixadmin's config.local.php file to 'dovecot:MD5-CRYPT' so it would use doveadm to generate the hash, but Postfixadmin barfed when I tried that. Here's why: doveadm wants to open the socket /run/dovecot/stats-writer (yet it doesn't seem to write anything as far as I can see), but if your user (apache in this case) has no permissions on the socket, you get an error message. The return code is still 0, but Postfixadmin treats it as an error because stderr from the call to doveadm has non-zero length.

So one way out of the problem would be to patch Postfixadmin to ignore what was written to stderr when the return code is zero. This is suboptimal for several reasons.

At this point some people on line suggest adjusting the permissions so that the intended user could write to that socket--say by putting Apache in the dovecot group--but I thought that the point of Dovecot was to enhance security, not weaken it. A writer in the Gentoo Forums a few years ago had a better take: set up a sudo rule to let the apache user execute sudo doveadm pw.

Others have talked about munging Dovecot hashes in PHP (including unsalted hashes), but this runs up against a different problem: Dovecot has changed its mind before and could do so again. I've read about authentication problems people have had with Dovecot updates.

If I had my druthers, the authority for the generating password hashes and checking their validity would reside in the database. This means using stored procedures both to hash passwords and to check user credentials. Only the owner of those procedures should have grants on the password table: I'd want to make it hard to pilfer my password hashes.

(I see that there is indeed a reason Dovecot might want to fetch from the password column of the database: it has to be able to deal with client-hashed passwords sent when the IMAP connection is not encrypted. Since I require that IMAP connections use TLS, I can happy accept SASL cleartext passwords--and don't need Dovecot to make hash.)

Configuring Dovecot to make such a change seems to be a matter of setting the stored procedure to return a row with password == NULL and nopassword == 'Y' when the credentials match and an empty row if not (Password verification by SQL server). Letting Roundcube set passwords now can avoid the hassle of setting up the execution of doveadm using proc_open. The problem is now Posfixadmin: I can't see how to make the change without patching the code.

A compromise to allow everything to remain unpatched (and also relieve me of the need to write the stored procedures) would be have PHP (whether Postfixadmin or the Roundcube plugin) generate passwords and store them in the password column. At this rate the hashes aren't as hidden, but at least they would not show up in any of the normal result sets from the database.

So does anyone have a suggestion about the best way to go?

[szatox]

Do you have a link to the specific guide you're using?
What is the part you actually have a problem with?

I'm using postfix + dovecot + mysql and a locally installed mail client. Database stores password hashes and mailbox-alias mapping, dovecot authenticates users, in case of mail submisison postfix defers to dovecot's verdict (via a unix socket)
I haven't used roundcube, but I think it's a webmail using regular imap + smtp client just like squirrelmail does, and probably should be treated just like any other mail client. Like in: The server-side config (postfix, dovecot and sql) shouldn't need any special tricks to enable it.

[miket]

[C5ace]

miket:

Have a lock at the manual, installation instructions and source of "ISPConfig"
www.ispconfig.org

They use Dovecot, Postix and mariadb /mysql.

The installer (ISPConfig-3.2.11p1.tar.gz) contains a unmaintained setup script "/ispconfig3_install/helper_scripts/gentoo_setup.sh" and various Gentoo related php scripts.

I run since many years a mail and web server using ISPconfig on a Debian VM. Never had to use Postfixadmin.
_________________
Observation after 30 years working with computers:
All software has known and unknown bugs and vulnerabilities. Especially software written in complex, unstable and object oriented languages such as perl, python, C++, C#, Rust and the likes.

[szatox]

[miket]

[miket]

[C5ace]