New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dovecotpw needs to read my TLS certificate and its private key #398
Comments
it's an issue with dovecot / doveadm, not technically postfixadmin. Although postfixadmin calls doveadm, which is why you see the problem. |
see also #379 |
see also - #382 - which probably has a fix |
Ok, I see, thank you. |
I don't know why; it's a dovecot change. |
I've reached out Dovecot developers asking if read access in For the auth problem, I see that it goes away with my workaround, but I don't understand why: if PostfixAdmin has direct access to the mail database, why it can't authenticate neither admins nor even regular users? How does the authentication work? It doesn't seem to use neither an auth socket created by Dovecot, nor the command |
I don't see it:
There's no such group as postfixadmin. And it complains about fullchain.pem:
|
You should use the main group of the user running the php-fpm pool for PostfixAdmin. Another way (not reccomended) is to make the file world readable via The group name depends on your system, it may be "www-data" in Ubuntu, the package in Arch Linux repos creates the specific user "postfixadmin" for this task. You could test it even with your normal user: if you don't have read access to /etc/dovecot/dovecot.conf and you run
If you are able to read dovecot.conf with your normal user, you get a similar error for other files you aren't allowed to read (as you already saw):
For instance, if you specified a dhparam file, you need to read it as well to create a password hash through |
|
$CONF['encrypt'] = 'dovecot:ARGON2I'; |
After the change and restart of apache2:
After another try, I got:
After I changed the value to system, I could create a new admin and change the password for another admin. This however didn't solve the problem that the only mail account created in the system kalmer@test.tennis24.ee only receives system log mails three times a day and no other mail will be received that I send to myself from other accounts. Sending out works well but not receiving. |
Well, I did it:
As you see, the system doesn't change the group for these files. All these files are world-readable anyway. But postfixadmin or dovecot still fails to get access to them. Meanwhile, checking for new messages to kalmer@test.tennis24.ee, I get an error message in Thunderbird for having an incorrect authentication method which is normal password. |
They appear world readable because files under "live" are links, however the real file permission could be (and probably are) different. By running that command directed to You should then check directory permissions, because even if the right files are accessible to the correct group, they may still be located behind inaccessible folders:
Once you modified the permissions correctly, you should see the following inside /etc/letsencrypt/archive/example.org
The only file that returns problem now is privkey1.pem, that you could either
Remember that folders need the execution permission, so you want 750 instead of 640 for a folder accessible by both owner and group. |
My file permissions seem to be suitable according to your suggestions:
Meanwhile, I was able to make kalmer@test.tennis24.ee to receive messages from outside by opening the port 25 for public. Currently, I have the following ports open for public: 22, 25, 80, 143, 443 and 587. Do I need some other ports to be open for public? Can that be connected to the issue that postfixadmin can't let me in because dovecot fails to read fullchain.pem? For logging in to kalmer@test.tennis24.ee using postfixadmin:
For setting up a new admin:
This time, the error message is different. It complains about missing ssl_dh. I have no idea what that is. To get an idea what that is, I digged around in Internet and found no answer. So I went to the page with instructions I followed while I was creating the whole mail server system for the first time and found in the comments section how to get rid of that erroneous situation:
There, I put:
Then:
After that, I could create a new admin and I could even log in to an admin account that I haven't deleted from the database. Why is everything else straightforward to set up but setting up a mail server system has 11 books of instructions with comments? |
Files seems good, if you run Note that Postfix and Dovecot can work well even if PostfixAdmin isn't working (or installed at all)
I don't think so. The ports I use for mail are:
Check out the link I sent before regarding Diffie-Hellman parameters:
I don't have anymore that option, but I use
I agree on that, I had to dig a lot of wikis, blog posts and documentations to get a fully modular setup. But when you achieve it, it gives you a sensation of pride and accomplishment that other services don't usually do. Congratulations, you did it 😉 |
Still no reply from Dovecot devs |
* update to alpine:3.13 and php8 * update postfixadmin to 3.3.4 * install new dependency: php8-pdo, php8-pdo_pgsql and php8-pdo_mysql * temporary workaround for doveadm pw reading server.key. See also postfixadmin/postfixadmin#398. * run upgrade.php at start * Update HASH lenght check. The HASH generated by setup.php is now 60 characters long.
Applying different permissions to key files is imho never a good solution. It is possible to workaround this issue. Create a file e.g. Then include this file in your Restart See this discussion for further reference. |
I knowm but I'd rather revoke those permissions whenever I don't need the postfixadmin (www-data) user to read my private TLS key (99.99% of the times, and it shouldn't be required in the first place even for that 0.01%). |
see also : #491 - probably needs rewriting again - but hopefully there's a solution in the making |
The
Good to know, thanks! |
Ok, I see, I can move secrets away from the main dovecot.conf using !include_try and strict permissions, and then make dovecot.conf world readable in order to get |
An alternative is through php_crypt and then modify the Dovecot password query against MariaDB. /etc/postfixadmin/config.local.php
/etc/dovecot/dovecot-sql.conf.ext
This doesn't add the the string for the encryption method in the database, but adds it in the result returned to Dovecot. For some unclear reason Dovecot needs this (the |
I really don't understand people. I'm reading the comments, and I see the people are juggling with system permissions and the security. · Having read permissions for others in dovecot configuration files allows anyone to read database passwords and other sensitive configuration. My · Adding the This issue was created 4 years ago. The stable version 3.3.13 (as of 2024-01-28) still has no native solution for I don't want a new and maybe unstable master branch on my system. Then, to solve this problem I created a small bash script that emulates the behavior of the · It does not need any special access to any file, because it does not read any file. Here is the source code. #!/bin/bash
# This script emulates the behavior of "doveadm pw". You can use it on PostfixAdmin
# for generating and checking argon2 hashes natively.
#
# The latest version of Dovecot requires access to /etc/dovecot/,
# /run/dovecot and /etc/letsencrypt/ when running "doveadm pw"
#
# Run doveadm pw is impossible without changing permissions to all the above files/folders
# or adding the dovecot group to the postifxadmin user. This is a security risk.
#
# To solve that without breaking the security use this script.
#
# 1. Copy this script to /usr/local/bin and set execution permission 0755.
# 2. Edit the file /etc/webapps/postfixadmin/config.local.php and insert the next line:
#
# $CONF['dovecotpw'] = '/usr/local/bin/postfixadmin-pw';
#
# That's all.
#
# Author: nobody
# Copyright = Copyleft = Copyup = Copydown = Copymadafaka
# You can do what do you want. It's your code. No mentions, no names on walls.
if [[ "$(stat -c "%a" "$0")" != "755" ]]; then
>&2 echo "Wrong file permissions. Must be 0755"
exit
fi
if [[ -p /dev/stdin ]]; then
IFS= read -r pass
if [[ "${4}" == {ARGON2ID}* ]]; then
v="$(echo -n ${4} | sed 's/.*v=\([0-9]\+\).*/\1/')"
v=$(printf "%x" $v) # version in hex (19 = 0x13)
m="$(echo -n ${4} | sed 's/.*m=\([0-9]\+\).*/\1/')"
t="$(echo -n ${4} | sed 's/.*t=\([0-9]\+\).*/\1/')"
p="$(echo -n ${4} | sed 's/.*p=\([0-9]\+\).*/\1/')"
salt="$(echo -n ${4} | sed 's/.*\$\([^$]\+\)$.*/\1/')"
pass_hash="$(echo -n ${4} | sed 's/.*\$.*\$\(.*\).*/\1/')"
salt_padding=$((4- ${#salt} % 4))
[[ $salt_padding -gt 0 ]] && [[ $salt_padding -lt 4 ]] && salt+="$(printf "=%.0s" $(seq 1 $salt_padding))"
salt=$(echo -n "$salt" | base64 -d)
new_hash=$(echo -n "$pass" | echo "{ARGON2ID}$(/usr/bin/argon2 "$salt" -id -k $m -t $t -p $p -e -v $v -l 32)")
new_pass_hash="$(echo -n "$new_hash" | sed 's/.*\$.*\$\(.*\).*/\1/')"
[[ "$pass_hash" = "$new_pass_hash" ]] && echo "$new_hash (verified)" || echo "Fatal: reverse password verification check failed: Password mismatch"
else
echo -n "$pass" | echo "{ARGON2ID}$(/usr/bin/argon2 $(openssl rand -hex 8) -id -k 65536 -t 3 -p 1 -e -v 13 -l 32)"
fi
else
>&2 echo "Missing password"
fi Have a nice life! |
thanks @mvasi90 |
My Hero! 👍 Completely agree, thank you so much! |
I can't find it documented anywhere and I also don't understand the logic behind this: why does PostfixAdmin need to read my TLS certificate private key to allow login or create users?
Postfix, Dovecot and IMAP clients work well with the default ownership and permissions settings of Let's Encrypt files and folders (probably because their master processes are run as root), however to login on PostfixAdmin or create an account I need to run, as root:
If settings are different from above, when logging in, the page will simply refresh, throwing this vague error in NginX error log:
By creating a new admin from setup.php the error gets more useful:
By changing ownership and permissions of only the directories /etc/letsencrypt/live and /etc/letsencrypt/archive, the error becomes:
The text was updated successfully, but these errors were encountered: