The default bug view has changed. See this FAQ.

Message: NO Access denied for GETACL on INBOX (ACL "a" required)

RESOLVED FIXED

Status

MailNews Core
Networking: IMAP
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: Peter Bieringer, Assigned: Bienvenu)

Tracking

({fixed1.8.1.1})

Trunk
x86
All
fixed1.8.1.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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?
(Reporter)

Comment 1

11 years ago
Same happen on 1.5/Windows and 1.0.7/Linux
OS: Windows 2000 → All
Version: unspecified → 1.5
(Reporter)

Comment 2

10 years ago
Same happen with 1.5.0.8/Linux

Does noone care about this bug???
(Assignee)

Comment 3

10 years ago
first I've seen of this bug...reassigning to the correct component...
Component: General → Networking: IMAP
Product: Thunderbird → Core
Version: 1.5 → Trunk
(Assignee)

Comment 4

10 years ago
There was one fix in this area in 2.0 - I don't know if it would fix your problem or not...
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

10 years ago
Problem still exists in thunderbird 2.0beta1
(Assignee)

Comment 6

10 years ago
 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.
(Assignee)

Comment 7

10 years ago
Ah, I see - rfc 4314 supercedes 2086 and is explicit that you need administer rights to do even GETACL. 
(Assignee)

Comment 8

10 years ago
Created attachment 249073 [details] [diff] [review]
proposed fix (untested)
Attachment #249073 - Flags: superreview?(mscott)
(Reporter)

Comment 9

10 years ago
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.
(Assignee)

Comment 10

10 years ago
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.
Attachment #249073 - Attachment is obsolete: true
Attachment #249110 - Flags: superreview?(mscott)
Attachment #249073 - Flags: superreview?(mscott)
(Reporter)

Comment 11

10 years ago
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.

(Assignee)

Comment 12

10 years ago
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...
Status: NEW → ASSIGNED
(Assignee)

Comment 13

10 years ago
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!
Attachment #249110 - Attachment is obsolete: true
Attachment #249110 - Flags: superreview?(mscott)
(Reporter)

Comment 14

10 years ago
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..                                                                                                                                                 
#
(Assignee)

Comment 15

10 years ago
Comment on attachment 249271 [details] [diff] [review]
an other approach

thx very much, Peter. We'll get this into 2.0
Attachment #249271 - Flags: superreview?(mscott)
(Reporter)

Comment 16

10 years ago
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.
(Assignee)

Comment 17

10 years ago
I can request approval for the 1.5.0.x tree, once it goes onto the trunk and 2.0 branch. 

Updated

10 years ago
Attachment #249271 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 18

10 years ago
fixed on trunk and branch
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.8.1.1
Resolution: --- → FIXED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.