I am running a working mail server with a postfix/dovecot on debian buster as in this guide. Like in the guide, I installed roundcube on the frontend.

The last chapter of the guide discusses encryption, and if you follow it, you end up with a per-user based encryption (in dovecot'sh, this is called "folder encr." as opposed to "global encr.").

This is a neat setup, and I am very happy with everything, except one point:

What bugs me:

Once a user changes his/her password, an admin would have to log onto the server and change the encryption key as well (as the mail_crypt plugin is configured to use the user's password..yea).

This has two downsides: First, the obvious "someone has to manually logon the remote to execute a command" part, that may get a bit annoying on a growing user base.. Second - and this concerns me from a security pov - would the admin have to know the user's old and new passwords. This is a no-no-go imho.

State of my art:

Smart as I am, I built a tiny little plugin on top of the password plugin that shall be triggered upon password changes. It then runs the doveadm command to adjust the crypto-keys.

So far so good...

Obviously, roundcube (and thus the plugin) runs with a different user than dovecot. This will, without further configuration lead to permission denied errors (in fact, the error messages are much more cryptic, but you get the idea.)

So what I did is change the dovecot user_query to utilize the web-user (instead of the mail user) and along that step changed the ownership of the Maildirs as well.

-> The plugin works fine, as the web-user now has full access to the Maildir.

The Problem / My question:

As all the mails are now owned by the very same user the webserver runs on, I cannot sleep tight and right knowing that some bug or wrong character in the wrong input field may lead to .. well.. just wrong results. (Although the mails are encrypted and nobody - not even root - may read them, the web-user may still remove the files for example..).

I do regular backups of the system, to be ahead of this worst case scenario. However just out of curiosity, do you guys see a better way to handle this case? Can I somehow escalate from web-user running the plugin to the mail user running doveadm, without the need of web-user owning (and hopefully not pwning) Maildir?

Thanks in advance - I hope this is the correct SE-page to ask this question anyway, and stay healthy!

Happy codin'


take a look here - https://gist.github.com/yajrendrag/203b0172fee96a8b002a026362d27bf2 - you can ignore everything related to postfixadmin (i modified it to work with the ISPMail guide including encryption), but look at the "2nd half" of the guide which specifically talks about encryption. but in steps & 7 i addressed the roundcube password change situation. I added this:

/* added to update crypto password when user changes password */
system ('sudo /usr/bin/doveadm mailbox cryptokey password -u '.escapeshellarg(self::username()).' -n '.escapeshellarg($passwd).' -o '.escapeshellarg($curpass));

to /usr/share/roundcube/plugins/password/password.php in the private function _save just after the case PASSWORD_SUCCESS line.

Also added $config['password_confirm_current'] = true; to the configuration in /etc/roundcube/plugins/password/config.inc.php so a user has to type their current password in order to change the password.

Guessing I probably did something similar to what you did in your plugin... but in addition, in step 9, i also added www-data ALL=(root) NOPASSWD: /usr/bin/doveadm to /etc/sudoers.d/local so www-data can execute doveadm as root without a password. You may consider this too insecure, but this way, i didn't have to make any change to file ownership and the server is just for me, so i was ok with it.

  • Welcome to serverfault :) Thank you for the answer. Unfortunately, it does not really help me. I wonder how I could "pass" the task to a different user mainly to seperate security concerns regarding webmail and mailserver.. giving root to your www-data user enables your users to take over your system if they find a bug. I want to minimize the potential damage, and I do it via unix permissions. I am looking for a way to (maybe) switch user without a password I guess. This way, even if the command gets compromised, vmail user could only damage mails, but not the web server owned by www-data. – randmin Mar 13 at 0:16
  • saw your answer below - (i can't comment below - in sufficient reputation points, but i can here presumably because it's my answer?) .. anyway, i was just thinking similar thing - maybe simple as changing (root) to (vmail) or did you do more than that? – J Gardner Mar 13 at 15:26
  • I recommend to make the sudoers-rule much more strict – sebix Mar 13 at 19:30
  • Yes I changed "root" in your example to "vmail". Other than this, my setup looks presumably just like yours. Please change your answer to reflect this change so I can vote it as "best". As I am asking from a security standpoint, this cannot be accepted as is – randmin Apr 25 at 17:28

I found this question enlightening:

Another better approach, change /etc/sudoers.d/myOverrides with:

<user> ALL= (<dummy user>) NOPASSWD:/path/to/chromium-browser

this allow to run /path/to/chromium-browser as without being prompt for password.

sudo -u <dummy user> -i /path/to/chromium-browser

I reversed the Mailbox ownerships from www-data to vmail and followed the instructions above.

I am pretty certain that this PAM-like solution is the most secure setup I can come up with for two reasons: A: We minimize the attack surface by separating the webmail-server from the actual Mailboxes (No, I am not paranoid) B: We still run both processes in an unprivileged environment (no root)

You are welcome to prove me wrong. (Actually, I would love to even turn off sudo completly for all other cases. Possible?...Maybe)

I leave this question "open" for someone that takes the time to make this more comprehensive and enlightening and earn the "best answer" tag. However, this works as a solution to me and maybe others :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.