Username used by dovecot to access database certificate and key files
Hi
does anyone happen to know the username under which dovecot accesses the certificate and key files when connecting to a mariadb database with ssl? I can't seem to get dovecot to read the files without a "other" readable bit set.
I have dovecot users in mysql with the following connect string in dovecot-sql.conf.ext
connect = host=x.x.x host=y.y.y host=z.z.z dbname=maildb user=mailuser
password=xxxxxx
ssl_ca=/etc/ssl/mysql/ca-cert.pem
ssl_cert=/etc/ssl/mysql/client-cert.pem
ssl_key=/etc/ssl/mysql/client-key.pem
ssl_verify_server_cert=yes
The certificate and key files in /etc/ssl/mysql/ are owned by root with group users:
ls -l /etc/ssl/mysql
total 12 -r--r--r--. 1 root root 2041 Jun 22 15:32 ca-cert.pem -r--r--r--. 1 root users 1907 Jun 22 15:32 client-cert.pem -r--r--r--. 1 root users 3272 Jun 22 15:32 client-key.pem
For my test dovecot, dovenull and vmail are all members of group users:
grep users /etc/group users:x:100:postfix,dovecot,dovenull,vmail
If I remove the "other" readable attribute on the certificate and key files, dovecot complains it can't connect to the db server:
auth: Error: mysql(x.x.x): Connect failed to database (maildb): TLS/SSL error: Permission denied (13) - waiting for 1 seconds before retry
I realize it only adds marginal security to not have these files world readable, but still it is puzzling why dovecot cannot read them in that case. Can anyone see what I am missing?
Thanks
John
On 08/12/2023 14:45 EET John Fawcett <john@voipsupport.it> wrote:
Hi
does anyone happen to know the username under which dovecot accesses the certificate and key files when connecting to a mariadb database with ssl? I can't seem to get dovecot to read the files without a "other" readable bit set.
I have dovecot users in mysql with the following connect string in dovecot-sql.conf.ext
connect = host=x.x.x host=y.y.y host=z.z.z dbname=maildb user=mailuser password=xxxxxx
ssl_ca=/etc/ssl/mysql/ca-cert.pem
ssl_cert=/etc/ssl/mysql/client-cert.pem
ssl_key=/etc/ssl/mysql/client-key.pem
ssl_verify_server_cert=yesThe certificate and key files in /etc/ssl/mysql/ are owned by root with group users:
ls -l /etc/ssl/mysql
total 12 -r--r--r--. 1 root root 2041 Jun 22 15:32 ca-cert.pem -r--r--r--. 1 root users 1907 Jun 22 15:32 client-cert.pem -r--r--r--. 1 root users 3272 Jun 22 15:32 client-key.pem
For my test dovecot, dovenull and vmail are all members of group users:
grep users /etc/group users:x:100:postfix,dovecot,dovenull,vmail
If I remove the "other" readable attribute on the certificate and key files, dovecot complains it can't connect to the db server:
auth: Error: mysql(x.x.x): Connect failed to database (maildb): TLS/SSL error: Permission denied (13) - waiting for 1 seconds before retry
I realize it only adds marginal security to not have these files world readable, but still it is puzzling why dovecot cannot read them in that case. Can anyone see what I am missing?
Thanks
John
The group depends on process, usually dovecot uses four different identities:
root, dovecot:dovecot, dovenull:dovenull and vmail:vmail (or per-user identity).
Any extra groups are removed during execution, but if you want, you can use
https://doc.dovecot.org/configuration_manual/service_configuration/#extra-gr...
like
service imap { ... extra_groups = users }
to grant the process users membership during execution.
Aki
On 08/12/2023 14:18, Aki Tuomi via dovecot wrote:
The group depends on process, usually dovecot uses four different identities:
root, dovecot:dovecot, dovenull:dovenull and vmail:vmail (or per-user identity).
Any extra groups are removed during execution, but if you want, you can use
https://doc.dovecot.org/configuration_manual/service_configuration/#extra-gr...
like
service imap { ... extra_groups = users }
to grant the process users membership during execution.
Aki
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Thanks Aki, with this info I solved it. I didn't get to the bottom of which process needed the extra_groups attribute, but changing the files group ownership to dovecot was just as good.
John
John Fawcett skrev den 2023-12-08 13:45:
I realize it only adds marginal security to not have these files world readable, but still it is puzzling why dovecot cannot read them in that case. Can anyone see what I am missing?
dovecot does imho not run anywhere with users group ?
default in gentoo all users is default in /home group subdirs, did you make mistakes here ?
private & public keys should only be owned and grouped as root, why ?, dovecot runs on ports below 1024, so all auth is loaded as root where it drops priveleges later !
dont make secureity mistakes
participants (3)
-
Aki Tuomi
-
Benny Pedersen
-
John Fawcett