Hello Everyone,
We published the following
Dovecot security update in cPanel & WHM version
78.0.10:
[security] Fixed case CPANEL-25461: Update cpanel-dovecot to 2.3.4.1-1 for CVE-2019-3814.
Included with this update is a change to the way the Dovecot
Local Mail Transfer Protocol (LMTP) handles local delivery attempts when it's unable to determine if quotas are enabled. Prior to this change, Dovecot quota errors like the ones below were logged to
/var/log/maillog:
Feb 25 03:10:11 server1 dovecot: lmtp(866): Error: Mailbox INBOX: quota: Failed to get quota resource STORAGE_BYTES for INBOX: quota-fs: quotactl(Q_GETQUOTA, /dev/simfs) failed: No such device
Feb 25 03:10:11 server1 dovecot: lmtp(866): Error: mailbox_get_status(INBOX, STATUS_CHECK_OVER_QUOTA) failed: Mailbox INBOX: quota: Failed to get quota resource STORAGE_BYTES for INBOX: quota-fs: quotactl(Q_GETQUOTA, /dev/simfs) failed: No such device
Feb 25 03:10:11 server1 dovecot: lmtp(866): Disconnect from local: Client has quit the connection (state=RCPT TO)
Feb 25 03:12:46 server1 dovecot: lmtp(1164): Connect from local
Feb 25 03:12:46 server1 dovecot: lmtp(1164): Disconnect from local: Client has quit the connection (state=GREETING
Prior to the update, these errors were non-fatal and the local delivery attempt succeeded.
The updated Dovecot version now considers these types of quota check errors to be fatal and thus aborts deliveries with an error message like this in
/var/log/exim_mainlog:
T=dovecot_virtual_delivery defer (-44): LMTP error after RCPT TO:<
[email protected]>: 451 4.3.0 <
[email protected]> Temporary internal error
We're currently evaluating reports of this issue as part of internal case CPANEL-26002. I'll monitor this case and update this thread with more information as it becomes available.
In the meantime, the workaround is to address the underlying cause of the quota errors seen in
/var/log/maillog.
The specific cause of the quota errors can vary from system to system, however most of the support requests we've received thus far stem from the
vzquota init script incorrectly running at boot time on virtual servers that were migrated from the
vzfs backend to the
ploop storage backend.
You can verify if that's the cause of the issue on your particular server by accessing the server via SSH as
root and running the following commands:
Code:
chkconfig --list | grep vzquota
diff -u /etc/mtab /proc/mounts
The output from the above commands will resemble the following on affected systems:
# chkconfig --list | grep vzquota
vzquota 0: off 1: off 2: on 3: on 4: on 5: on 6: off
# diff -u /etc/mtab /proc/mounts
--- /etc/mtab 2019-02-25 12:38:42.637938881 +0100
+++ /proc/mounts 2019-02-26 00:55:11.314517060 +0100
@@ -1,4 +1,4 @@
-/dev/simfs / reiserfs rw,usrquota,grpquota 0 0
+/dev/ploop11777p1 / ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0
....
Notice that
vzquota is set to "on" at run levels 2, 3, 4, and 5 (this confirms it runs at boot time). Then, notice how
/etc/mtab uses
/dev/simfs, whereas
/proc/mounts uses
/dev/ploop$$. The difference exists because the
vzquota init script incorrectly changes "ploop" to "simfs" in the
/etc/mtab file at boot time time (
/etc/mtab should instead exist as a symbolic link to
/proc/mounts on these systems).
If the output
does not look like this on your system, then it's likely there's a different underlying cause of the quota errors on your system. In such cases, feel free to respond to this thread with the error message you see in
/var/log/maillog and we'll be happy to help you diagnose the problem.
Upon confirming the system is affected by this particular issue, you can run the following commands to fix this:
Code:
chkconfig --level 234 vzquota off
mv -v /etc/mtab{,.old}
ln -s /proc/mounts /etc/mtab
reboot
These commands disable
vzquota at boot time, setup
/etc/mtab is a symbolic link to
/proc/mounts, and reboot the server.
Let us know if you have any questions.
Thank you.
Edit Log:
03/06/2019: Updated case number to CPANEL-26002.
03/01/2019: Updated the workaround instructions to note the commands should be ran on the individual server.
