[Dovecot] /etc/passwd Centos + dovecot

[Ben Morrow]

At 10PM +0200 on 25/06/13 you (Reindl Harald) wrote:
> Am 25.06.2013 16:59, schrieb Paolo Andretta:
> > On Tue, 25 Jun 2013, Dejan Doder wrote:
> > 
> >> Hi group , I use system users with passwords defined in /etc/passwd.
> >> How can users change their passwords ?
> > 
> > I don't think this is dovecot related, but you can use squirrelmail
> > + plug-in or roundcube + plugin or directly
> > with a web interface to poppassd or usermin, or ...
> 
> with a great impact on security at all
> 
> * a sane webserver does not allow scripts exec()
> * you do *not* want the passwd command invoked from a website
> 
> it is a broken design using system users and consider password changes
> for the users via whatever enduser procotol - virtual users stored
> in a database are the way to go if security matters

While I agree you want to keep passwords somewhere other than
/etc/passwd (specifically, somewhere that does not require direct root
access to change them), this is not incompatible with using system
users. 

In my setup, I use system users, both for security reasons (it's more
secure to have different users' imap processes running under different
uids) and for the convenience of having one password across all
services, but rather than keeping the passwords in /etc/passwd I keep
them in Kerberos. This means the Dovecot auth-worker service doesn't
need to run as root, it just needs a keytab it can verify users' tickets
against, and the webmail password-changing interface can change a
password without needing any special privileges.

On the Dovecot side I use userdb passwd and passdb pam, with the
'dovecot' PAM service configured to use pam_krb5, and on the webmail
side I use Roundcube with the 'password' plugin, configured to use PAM,
with the 'php' PAM service also configured to use pam_krb5. (I had to
patch pecl-pam to get it to pass the old and new passwords in properly
with pam_set_item rather than using a conversation function and guessing
at the prompts, but that's just expected PHP flakiness. I wish I could
find a decent Perl webmail system...)

I would imagine it would be straightforward to set up something similar
with passwords in LDAP or SQL: the important thing is to set things up
so that you check the passwords via PAM, so that different services will
see the same passwords. The advantage of Kerberos or (I think) LDAP over
SQL or anything similar is that once you've authenticated against the
system (using the user's current password) you can change the password
without any additional privilege. I think with SQL you would need to
give PHP write access to the database, which sounds like a very bad
idea. Possibly you could set something up with Postgres and a SECURITY
DEFINER stored procedure, but I don't know how easy that would be.

Obviously it goes without saying that you want to be very careful to
make it impossible to change (say) root's password like this. In my case
root's password actually does live in /etc/passwd, so anything not
running as root cannot possibly change it.

Ben