[Dovecot] /etc/passwd Centos + dovecot
Hi group , I use system users with passwords defined in /etc/passwd. How can users change their passwords ?
BR Dejan
On 2013-06-25 4:21 AM, Dejan Doder doderde@gmail.com wrote:
Hi group , I use system users with passwords defined in /etc/passwd. How can users change their passwords ?
Sorry, wrong list. This is not a dovecot function, this is a function of user management.
Personally, I use postfixadmin (but I also disallow users to change their own passwords)...
--
Best regards,
Charles
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 ...
--
Regards, Paolo
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
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
participants (5)
-
Ben Morrow
-
Charles Marcus
-
Dejan Doder
-
Paolo Andretta
-
Reindl Harald