Description of problem: When the quota is set for 2,000,000 (which ends up being 2gb) there is no error. Setting the quota to 5,000,000 (or 5gb) the clients receive an over quota error and all delivery stops. Setting it to 7,000,000 (or 7gb) seems to cure the problem. There seems to be some problem witht he math being used in the original quota patch. Version-Release number of selected component (if applicable): cyrus-imapd- 2.2.10-1.RHEL4.1 How reproducible: Every time Steps to Reproduce: 1. create an email account with a 2gb quota and fill it 90% 2. set quota to 5gb 3. test with Outlook or Horde web based client (or any client that is imap quota compliant). Actual results: Client received over quota message. Verified quota user of 36%. Mail was returned for being over quota. I reverted the quota settings back and then played with them for a little while to find out that the error was based in blocks. Expected results: Client should not have been presented with any quota message. Additional info: I verfied this with outlook express and horde web based client. Both clients support imap quota reporting. Both clients supported the results printed above. Problem was first reported by a user that was getting over quota limits on an account with 1.8gb. We had recently updated the account to allow for 5gb of mail. We verified that account had plenty of space (5gb or 5,000,000 available). Some accounts that have only a couple hundred MB of mail with the 5GB quota do not show this syptom. I understand that the quota patch does a divide by 1024 to work around the 32but int issue. It seems that the quota check math has some type of bug in it. good: 2,000,000 3,000,000 4,100,000 bad: 4,300,000 6,000,000 good: 7,100,000 bad: 15,000,000 good: 20,000,000 It's not a production down situation if we pick an arbitrarily large good number but this defeats quota management. Here is the error that we receive when we the server receivs an email: Nov 21 18:17:37 cyrustest lmtpunix[21925]: accepted connection Nov 21 18:17:37 cyrustest lmtpunix[21925]: lmtp connection preauth'd as postman Nov 21 18:17:37 cyrustest master[21960]: about to exec /usr/lib/cyrus- imapd/lmtpd Nov 21 18:17:37 cyrustest lmtpunix[21925]: verify_user(user.test16) failed: Over quota Nov 21 18:17:37 cyrustest lmtpunix[21960]: executed Nov 21 18:17:37 cyrustest postfix/pipe[21804]: DAA4638129: to=<test16@localhost>, relay=cyrus, delay=0, status=deferred (temporary failure)
I tracked down the function call in the log file and I think I have found the root problem. Here is the code fragment /imap/append.c if (m.quota.limit >= 0 && quotacheck >= 0 && m.quota.used + quotacheck > ((unsigned) m.quota.limit * QUOTA_UNITS)) { r = IMAP_QUOTA_EXCEEDED; If you see, m.quota.limit is being multiplied by quota_units which can results in an overflow which, if it's 1 over max would be 0. So, 10,000,000 (or 10gb based on the 1024 quota_units multiplier would give a theoretical quota of 1,400,000 (or 1.4gb) which would be under the 1.8gb of space being used by the accounts in question. So, from here we can calculate numbers that would always cause a threshold error based on the current quota usage in the user account. This seems to have been fixed in cyrus cvs (https://bugzilla.andrew.cmu.edu/cgi- bin/cvsweb.cgi/src/cyrus/imap/append.c.diff?r1=1.102&r2=1.102.2.9) but missed in this implementation.
One last comment, it appears that the fix was made back in February by the cyrus team on the 1.102 thread but it does not exist in the 1.107 thread. I'm not sure if they didn't port the change forward, have a reason not to port it forward or if they just botched it. https://bugzilla.andrew.cmu.edu/cgi- bin/cvsweb.cgi/src/cyrus/imap/append.c.diff?r1=1.107&r2=1.102.2.9 You will see that the 1.102 change is never (by nine months) than the version for the newer 1.107 tree.
Created attachment 121333 [details] Modifies 3 files to help out with the quota patch This patch is not optimized. I assumed a possible div/0 and then realized they didn't check anywhere else. The authors did a couple multiplications that would easily exceed the 32 bit integer. Instead of multiplying the affected values I have just divided the other values to bring them down to the same value expected by the rest of the application. This value is only used for comparison to see if the quota has been exceeded. This might have already been fixed in a later version of Cyrus but I didn't want to merge tree's to cause more problems. This patch seems to fix our problem in development but I'm also not sure if it covers all of the possibly cases that might throw a quota exception. YMMV
The bug seems to be fixed here -> https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1212 It's a very very evil bug, specially when we use Groupware like kolab !
My patch seems to work but I will check out theirs as well. I just don't want to implement something in production that will popup another issue. What is concerning is that this bug fix is for 2.2.6 and yet it still isn't in the upstream 2.2.10 package. But I do like thier approach though. It will just take some testing.
the problem is clearly a overflow of the (long) type. So, use a (long long) is, I think, the simplest way. I think this bug is very important, because cyrus-imapd is used by kolab, so large account is a frequent case (256 accounts in my case :) The only "workaround" is to disable quotas ... not a good idea I think. Maybe Redhat should quickly start testing this patch or take contact with the cyrus-imap dev team.
The proposed patch (which uses division instead of multiplication) may be not 100% correct, but nothing serious i believe. The other option is to go with long long for arithmetic as this should work on all our supported arches.
Created attachment 131783 [details] patch to fix overflow quota on cyrus-imapd-2.2.12-3gral / cyrus-imapd-2.2.12-3.RHEL4.1
The patch id=131783 (a modified version of https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2690) is curretly tested in a production server (300 users), hope it will work ...
(In reply to comment #12) > The patch id=131783 (a modified version of > https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2690) is curretly tested in a > production server (300 users), hope it will work ... > > > Does not work: because of conflict with patchs: cyrus-imapd-2.2.7-autocreate-0.2.diff and cyrus-imapd-2.2.7-autosieve-0.1.diff
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Any news? patchs for test?
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0258.html
Warning: when the cyrus-imapd is updated (on i386 32bit system) to version cyrus-imapd-2.2.12-8.1.RHEL4 the quota file is corrupt! Before this version, quotas are encoded in 32bits, now 64 ... so the problem is there. The only solution is to log in "cyrus" user, and launch theses commands: /usr/lib/cyrus-imapd/reconstruct (could take a long time) and /usr/lib/cyrus-imapd/quota -f now the quotas are ok. Maybe it should be useful to add this warning in a bulletin or upgrade notice. Regards jean-sebastien Hubert.