Dovecot logging to files causes issues
I have a mailing server setup based on Debian Stable that uses postfix (v3.7.10) for SMTP and dovecot (v2.3.19.1 (9b53102964)) for IMAP. I now wanted to set dovecot to not write to syslog, but to dedicated files in /var/log/dovecot. While everything indicates that this happens successfully as the log files gain in size, I also get lots of these errors:
May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=user@domain.de, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred (temporary failure. Command output: lda(user): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't open log file /var/log/dovecot/error.log: Permission denied )
If it would only log the complaints I wouldn't worry, but as long as I don't revert the changes in dovecot's config, mail receiving is at least vastly delayed, most likely stuck alltogether. So how am I supposed to set these settings?
I've chainged these settings in /etc/dovecot/conf.d/10-logging.conf:
log_path = /var/log/dovecot/error.log
debug_log_path = /var/log/dovecot/debug.log
log_debug = category=errorThe whole directory /var/log/dovecot is owned by dovecot:dovecot, permissions on debug.log, error.log and info.log are 644.
Best
Richard
On 19/05/24 04:31, Richard Rosner via dovecot wrote:
I have a mailing server setup based on Debian Stable that uses postfix (v3.7.10) for SMTP and dovecot (v2.3.19.1 (9b53102964)) for IMAP. I now wanted to set dovecot to not write to syslog, but to dedicated files in /var/log/dovecot. While everything indicates that this happens successfully as the log files gain in size, I also get lots of these errors:
May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=user@domain.de, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred (temporary failure. Command output: lda(user): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't open log file /var/log/dovecot/error.log: Permission denied )
If it would only log the complaints I wouldn't worry, but as long as I don't revert the changes in dovecot's config, mail receiving is at least vastly delayed, most likely stuck alltogether. So how am I supposed to set these settings?
I've chainged these settings in /etc/dovecot/conf.d/10-logging.conf:
log_path = /var/log/dovecot/error.log debug_log_path = /var/log/dovecot/debug.log log_debug = category=error
The whole directory /var/log/dovecot is owned by dovecot:dovecot, permissions on debug.log, error.log and info.log are 644.
Check the permissions of the entire path, as dovecot:
namei -l /var/log/dovecot/error.log
It might be selinux, check your audit.log file, or set selinux to permissive mode and see if it works:
setenforce 0
It might also be apparmour (sorry don't have instructions for apparmour).
The message basically means that something is preventing the dovecot user from writing to the file, you need to figure out what that is.
Peter
Am 19.05.24 um 04:02 schrieb Peter via dovecot:
Check the permissions of the entire path, as dovecot:
namei -l /var/log/dovecot/error.log
It might be selinux, check your audit.log file, or set selinux to permissive mode and see if it works:
setenforce 0
This can't be the case, there is no SELinux present by default in Debian and it was never installed on that server. For completeness, here's the output:
namei -l /var/log/dovecot/error.log f: /var/log/dovecot/error.log drwxr-xr-x root root / drwxr-xr-x root root var drwxr-xr-x root root log drw-rw-r-- dovecot dovecot dovecot -rw-r--r-- dovecot dovecot error.log
It might also be apparmour (sorry don't have instructions for apparmour).
The message basically means that something is preventing the dovecot user from writing to the file, you need to figure out what that is.
Peter
I can say that this isn't possible, as any AppArmor actions would be logged, so they would have showed up. And by the files sizes, Dovecot is clearly writing to them.
-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log -rw-r--r-- 1 dovecot dovecot 37K 14. Mai 14:05 error.log -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log
So there's pretty much no possibility AppArmor could have any involvement here. Also, usually when AppArmor prevents access to a directory, you'd get a "file not found" error, not a permission denied.
For the very unlikely case that AppArmor is the cause, these are the only rules present for dovecot:
Dovecot has two files. In tunables you can find this:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories
# where dovecot is allowed to store and read mails
#
# The default value is quite broad to avoid breaking existing setups.
# Please change @{DOVECOT_MAILSTORE} to (only) contain the directory
# you use, and remove everything else.
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mailWhich doesn't seem to be relevant for this. No idea how dovecot can put the mail into /maildirs/username, but since that's working I'm not complaining. The file in abstractions only contains this:
# used with dovecot/*
abi <abi/3.0>,
capability setgid,
deny capability block_suspend,
# dovecot's master can send us signals
signal receive peer=dovecot,
owner @{run}/dovecot/config rw,
# Include additions to the abstraction
include if exists <abstractions/dovecot-common.d>Richard
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile.
On 19.05.24 12:25, Richard Rosner via dovecot dovecot@dovecot.org wrote:
Am 19.05.24 um 04:02 schrieb Peter via dovecot:
Check the permissions of the entire path, as dovecot:
namei -l /var/log/dovecot/error.log
It might be selinux, check your audit.log file, or set selinux to permissive mode and see if it works:
setenforce 0
This can't be the case, there is no SELinux present by default in Debian and it was never installed on that server. For completeness, here's the output:
namei -l /var/log/dovecot/error.log f: /var/log/dovecot/error.log drwxr-xr-x root root / drwxr-xr-x root root var drwxr-xr-x root root log drw-rw-r-- dovecot dovecot dovecot -rw-r--r-- dovecot dovecot error.log
It might also be apparmour (sorry don't have instructions for apparmour).
The message basically means that something is preventing the dovecot user from writing to the file, you need to figure out what that is.
Peter
I can say that this isn't possible, as any AppArmor actions would be logged, so they would have showed up. And by the files sizes, Dovecot is clearly writing to them.
-rw-r--r-- 1 dovecot dovecot 0 13. Mai 20:50 debug.log -rw-r--r-- 1 dovecot dovecot 37K 14. Mai 14:05 error.log -rw-r--r-- 1 dovecot dovecot 40K 13. Mai 21:20 info.log
So there's pretty much no possibility AppArmor could have any involvement here. Also, usually when AppArmor prevents access to a directory, you'd get a "file not found" error, not a permission denied.
For the very unlikely case that AppArmor is the cause, these are the only rules present for dovecot:
Dovecot has two files. In tunables you can find this:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories # where dovecot is allowed to store and read mails # # The default value is quite broad to avoid breaking existing setups. # Please change @{DOVECOT_MAILSTORE} to (only) contain the directory # you use, and remove everything else.
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail
Which doesn't seem to be relevant for this. No idea how dovecot can put the mail into /maildirs/username, but since that's working I'm not complaining. The file in abstractions only contains this:
# used with dovecot/*
abi
, capability setgid,
deny capability block_suspend,
# dovecot's master can send us signals signal receive peer=dovecot,
owner @{run}/dovecot/config rw,
# Include additions to the abstraction include if exists
Richard
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot:
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not.
Am 19.05.2024 um 15:55 schrieb Richard Rosner via dovecot:
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution
Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot: permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not.
chmod ug+x on the /var/log/dovecot directory! Standard POSIX permissions for a non-root process to enter a directory.
Am 19.05.24 um 16:02 schrieb Alexander Dallou via dovecot:
Am 19.05.2024 um 15:55 schrieb Richard Rosner via dovecot:
Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot:
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not.
chmod ug+x on the /var/log/dovecot directory! Standard POSIX permissions for a non-root process to enter a directory. It most certainly isn't. nginx isn't running as root, yet it can log without execution permissions just fine. Absolutely nothing should have execution permissions if they aren't meant to be executed, which should only be true for a very small set of files besides binaries.
As Alexander wrote - posix behaviour. To change into a directory the directory itself needs execute permission for owner/group/other (what ever is meant). Not the file itself. BTW even a chmod 110 /var/log/dovecot (so only execute and no read/write) would work.
On 19.05.24 16:49, Richard Rosner via dovecot dovecot@dovecot.org wrote:
Am 19.05.24 um 16:02 schrieb Alexander Dallou via dovecot:
Am 19.05.2024 um 15:55 schrieb Richard Rosner via dovecot:
Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot:
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not.
chmod ug+x on the /var/log/dovecot directory! Standard POSIX permissions for a non-root process to enter a directory. It most certainly isn't. nginx isn't running as root, yet it can log without execution permissions just fine. Absolutely nothing should have execution permissions if they aren't meant to be executed, which should only be true for a very small set of files besides binaries.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Am 19.05.2024 um 16:49 schrieb Richard Rosner via dovecot:
It most certainly isn't. nginx isn't running as root, yet it can log without execution permissions just fine. Absolutely nothing should have execution permissions if they aren't meant to be executed, which should only be true for a very small set of files besides binaries.
Kind of off-topic, anyhow.
If your Nginx serves on ports lower than 1024, which you typically do with port 80 and/or port 443, then the master process of Nginx must run as the root user. And that process handles the logging. The worker processes can of course run as a non privileged user.
Am 19.05.2024 um 16:49 schrieb Richard Rosner via dovecot:
It most certainly isn't. nginx isn't running as root, yet it can log without execution permissions just fine. Absolutely nothing should have execution permissions if they aren't meant to be executed, which should only be true for a very small set of files besides binaries.
Kind of off-topic, anyhow.
If your Nginx serves on ports lower than 1024, which you typically do with port 80 and/or port 443, then the master process of Nginx must run as the root user. And that process handles the logging. The worker processes can of course run as a non privileged user.
That is not entirely true. If you run containers with linux capabilities you can just assign low ports.
On 20/05/24 01:55, Richard Rosner via dovecot wrote:
chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution
Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot: permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not.
What the x permission does for directories is different than what it does for files. For directories the x permission allows access to the files in a directory (the "search" permission). Without the x bit you will get a permissions error (just like you're getting).
Peter
participants (5)
-
Alexander Dallou
-
friedrich.kink＠fkink.de
-
Marc
-
Peter
-
Richard Rosner