Last Comment Bug 319535 - Message: NO Access denied for GETACL on INBOX (ACL "a" required)
: Message: NO Access denied for GETACL on INBOX (ACL "a" required)
Status: RESOLVED FIXED
: fixed1.8.1.1
Product: MailNews Core
Classification: Components
Component: Networking: IMAP (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: David :Bienvenu
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-08 02:16 PST by Peter Bieringer
Modified: 2009-01-22 10:17 PST (History)
0 users
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
proposed fix (untested) (1.05 KB, patch)
2006-12-18 20:26 PST, David :Bienvenu
no flags Details | Diff | Review
proposed fix (2.24 KB, patch)
2006-12-19 08:13 PST, David :Bienvenu
no flags Details | Diff | Review
an other approach (1.38 KB, patch)
2006-12-20 11:19 PST, David :Bienvenu
mscott: superreview+
Details | Diff | Review

Description Peter Bieringer 2005-12-08 02:16:03 PST
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?
Comment 1 Peter Bieringer 2006-01-12 03:41:18 PST
Same happen on 1.5/Windows and 1.0.7/Linux
Comment 2 Peter Bieringer 2006-12-18 04:50:35 PST
Same happen with 1.5.0.8/Linux

Does noone care about this bug???
Comment 3 David :Bienvenu 2006-12-18 07:08:51 PST
first I've seen of this bug...reassigning to the correct component...
Comment 4 David :Bienvenu 2006-12-18 07:09:40 PST
There was one fix in this area in 2.0 - I don't know if it would fix your problem or not...
Comment 5 Peter Bieringer 2006-12-18 12:42:15 PST
Problem still exists in thunderbird 2.0beta1
Comment 6 David :Bienvenu 2006-12-18 19:29:52 PST
 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.
Comment 7 David :Bienvenu 2006-12-18 19:36:15 PST
Ah, I see - rfc 4314 supercedes 2086 and is explicit that you need administer rights to do even GETACL. 
Comment 8 David :Bienvenu 2006-12-18 20:26:52 PST
Created attachment 249073 [details] [diff] [review]
proposed fix (untested)
Comment 9 Peter Bieringer 2006-12-19 04:46:43 PST
I've rebuilded 1.5.0.8 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.
Comment 10 David :Bienvenu 2006-12-19 08:13:02 PST
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.
Comment 11 Peter Bieringer 2006-12-20 04:09:21 PST
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.

Comment 12 David :Bienvenu 2006-12-20 09:05:37 PST
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...
Comment 13 David :Bienvenu 2006-12-20 11:19:18 PST
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!
Comment 14 Peter Bieringer 2006-12-21 12:37:06 PST
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 15 David :Bienvenu 2006-12-21 12:38:32 PST
Comment on attachment 249271 [details] [diff] [review]
an other approach

thx very much, Peter. We'll get this into 2.0
Comment 16 Peter Bieringer 2006-12-21 12:41:05 PST
Can you push it also into the 1.5 tree? I ran the test on a rebuilded 1.5.0.9 from Fedora Core 6.
Comment 17 David :Bienvenu 2006-12-21 12:43:01 PST
I can request approval for the 1.5.0.x tree, once it goes onto the trunk and 2.0 branch. 
Comment 18 David :Bienvenu 2006-12-22 05:42:17 PST
fixed on trunk and branch

Note You need to log in before you can comment on or make changes to this bug.