User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7 Build Identifier: Mozilla/5.0 version 1.0.7 (20050923) / 1.5rc1 If Thunderbird or Mozilla/IMAP connects to a courier-imap server with per user disabled shared folders, a message box occurs with following contents: NO Access denied for GETACL on INBOX (ACL "a" required) Reproducible: Always Steps to Reproduce: 1. Configure server side: courier-imap version 4.0.6 with per user disabled shared folders by e.g.: /etc/authlib/authdaemonrc: DEFAULTOPTIONS="disableshared=1" 2. IMAP login with Thunderbird 3. Select a folder Actual Results: Message box occurs: NO Access denied for GETACL on INBOX (ACL "a" required) Expected Results: No such message box I had some discussions with the courier-imap author resulting that it is perhaps more a problem in the IMAP client than in the server implementation. For tracking this more down, I catched packets with ngrep: With disabled shared folders: T client:1341 -> server:143 [AP] A00011 MYRIGHTS INBOX.. # T server:143 -> client:1341 [AP] * MYRIGHTS "INBOX" "cdilrsw"..A00011 OK MYRIGHTS completed... # T client:1340 -> server:143 [AP] A00003 GETACL INBOX.. ## T server:143 -> client:1340 [AP] A00003 NO Access denied for GETACL on INBOX (ACL "a" required).. With shared folders per user enabled: T server:143 -> client:1347 [AP] * MYRIGHTS "INBOX" "acdilrsw"..A00011 OK MYRIGHTS completed... # T client:1346 -> server:143 [AP] A00003 GETACL INBOX.. ## T server:143 -> client:1346 [AP] * ACL "INBOX" "owner" "acdilrsw"..A00003 OK GETACL completed... Note that MYRIGHTS shows now an additional "a". courier-imap author told me that an IMAP client cannot assume that it has administrative rights on any mailbox, even INBOX. And removing the ACL string from the capability string before login probably won't help because clients could read the server's capabilities prior to logging in, and assume they remain the same. Also the GETACL command requires the administrative right, the "a" ACL. This check is correct, because this operation requires ACL "a" privileges, which client don't have when shared support is disabled BTW: Mulberry shows the same message, if "Details" are requested from an INBOX. Why doesn't the client check for the "a" flag of MYRIGHTS and drop GETACL, if missing?
Same happen on 1.5/Windows and 1.0.7/Linux
Same happen with 188.8.131.52/Linux Does noone care about this bug???
first I've seen of this bug...reassigning to the correct component...
There was one fix in this area in 2.0 - I don't know if it would fix your problem or not...
Problem still exists in thunderbird 2.0beta1
From RFC 2086, MYRIGHTS a - administer (perform SETACL) So I can see why SETACL would fail, but not really GETACL. I'll look some more through the RFC and see if I'm missing something.
Ah, I see - rfc 4314 supercedes 2086 and is explicit that you need administer rights to do even GETACL.
Created attachment 249073 [details] [diff] [review] proposed fix (untested)
I've rebuilded 184.108.40.206 on Fedora Core 6 with your patch, but it doesn't fix this issue. On accessing any custom IMAP folder, the error text was shown.
Created attachment 249110 [details] [diff] [review] proposed fix Oh, great, so you can test the fix - can you try this patch? We were issuing the GETACL before MYRIGHTS, but your protocol snippets led me to believe we were doing myrights before acl...in order for my other change to work, we need to be doing MYRIGHTS first.
Second patch also won't work. Procedure: 1. log into INBOX of IMAP server -> ok 2. select folder "antivirus" -> error message is displayed I've captured related packets: T client:54958 -> server:143 [AP] 4 myrights "INBOX.antivirus".. ## T server:143 -> client:54958 [AP] * MYRIGHTS "INBOX.antivirus" "cdilrsw"..4 OK MYRIGHTS completed... # T client:54958 -> server:143 [AP] 5 getacl "INBOX.antivirus".. # T server:143 -> client:54958 [AP] 5 NO Access denied for GETACL on INBOX.antivirus (ACL "a" required).. ## T client:54958 -> server:143 [AP] 6 IDLE.. # Digging through your code and patch I found that your fix can't work. In patched function void nsImapProtocol::RefreshACLForFolder(const char *mailboxName) follwing will be called: GetMyRightsForFolder(mailboxName); GetACLForFolder(mailboxName); But GetACLForFolder does not check itself results of GetMyRightsForFolder. Suggestion: either GetACLForFolder checks result (the missing "a") of GetMyRightsForFolder or skip call of GetACLForFolder, if no "a" permission exists.
it's a little more complicated than that - we don't call RefreshACLForFolder if we know we don't have administrative rights for the folder - it's called from RefreshACLForFolderIfNecessary, which checks GetFolderNeedsACLListed(). So if we've ever done a myrights on the folder, and determined that we don't have 'a' rights, we shouldn't call RefreshACLForFolder. Are you trying this on folders you've clicked on before? If that's not working, that sounds like we're not caching the myrights response... You're right that for the first time check, we need to push the 'a' check lower down from where it is now...
Created attachment 249271 [details] [diff] [review] an other approach OK, can you try this one? I think with this approach, we don't need the change to nsImapMailFolder.cpp - we can just check in nsImapProtocol if the previous call to MYRIGHTS set the administer flag...Thx!
Your 3rd patch looks like fixing this issue. The error message is no longer displayed. Captured traffic shows now: T server:143 -> client:60249 [AP] * MYRIGHTS "INBOX.antivirus" "cdilrsw"..4 OK MYRIGHTS completed... # T client:60249 -> server:143 [AP] 5 getquotaroot "INBOX.antivirus".. # T server:143 -> client:60249 [AP] * QUOTAROOT "INBOX.antivirus" "ROOT"..* QUOTA "ROOT"..5 OK GETQUOTAROOT Ok... # T client:60249 -> server:143 [AP] 6 IDLE.. #
Comment on attachment 249271 [details] [diff] [review] an other approach thx very much, Peter. We'll get this into 2.0
Can you push it also into the 1.5 tree? I ran the test on a rebuilded 220.127.116.11 from Fedora Core 6.
I can request approval for the 1.5.0.x tree, once it goes onto the trunk and 2.0 branch.
fixed on trunk and branch