Closed Bug 377900 Opened 17 years ago Closed 17 years ago

RFC 4314 IMAP ACL delete rights are not honored

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: wbreyha, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1.4)

Attachments

(2 files)

IMAP Log
64.16 KB, application/x-gzip
Details
possible fix
2.17 KB, patch
mscott
: superreview+
dveditz
: approval1.8.1.4+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Thunderbird 2.0.0.0 (X11/20070326)

Working with Thunderbird 2.0.0.0 on cyrus 2.2.13 works well with RFC 2086 ACLs.
But working on cyrus 2.3.8 with RFC 4314 ACLs makes it impossible to delete mails since the "Delete Message" context menu is greyed out.

The cyrus in question announces the following capabilities:
* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH

It seems that Thunderbird 2.0.0.0 does not recognize the "RIGHTS=kxte" part, since all the mailboxes in question are set to "Full Control" for the owner.

It was no problem with 1.5.0.x to work on cyrus 2.3.x releases with rfc 4314 ACLs so far.

Reproducible: Always

Steps to Reproduce:
1. access an IMAP account on a server with RFC 4314 ACLs.
2. try to delete a message with "del" or via context menu
3.
Actual Results:  
unable to delete messages

Expected Results:  
the ability to delete messages;-)
As you write down full CAPABILTY of new cyrus 2.3.8, problem looks to be clear.
But IMAP protocol log is very helpful for developers to analyze problem.
Get NSPR log, and attach log file to this bug thru "Add an attachment" link, please. ( mime-type="text/plain" if file size is accepted. )
  http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
  http://www.mozilla.org/projects/netlib/http/http-debugging.html
"export(or setenv) NSPR_LOG_MODULES imap:5" is sufficient, I think.
Attached file IMAP Log — 
In this log you'll see access to imap.univie.ac.at (cyrus 2.2.x) which works fine and access to mail.sproing.at (cyrus 2.3.x) which makes troubles since deleting messages is impossible. The log includes a full session from start of thunderbird until closing it after an initial check of all 4 mailboxes (1 at imap.univie.ac.at, 3 at mail.sproing.at).
Attachment #262097 - Attachment mime type: text/plain → application/x-gzip
(In reply to comment #2)
> IMAP Log
Difference of CAPABILTY response.
  mail.sproing.at                 imap.univie.ac.at
  (Cyrus IMAP4 v2.3.8-Sproing-5)  (Cyrus IMAP4 Murder v2.2.13)
    IMAP4                           IMAP4
    IMAP4rev1                       IMAP4rev1
    ACL                             ACL
    ANNOTATEMORE                    ANNOTATEMORE
    AUTH=CRAM-MD5                   ---
    BINARY                          BINARY
    CATENATE                        ---
    CHILDREN                        CHILDREN
    CONDSTORE                       ---
    ID                              ---
    IDLE                            IDLE
    LIST-SUBSCRIBED                 ---
    LISTEXT                         ---
    LITERAL+                        ---
    MAILBOX-REFERRALS               MAILBOX-REFERRALS
    MULTIAPPEND                     MULTIAPPEND          
    NAMESPACE                       NAMESPACE            
    NO_ATOMIC_RENAME                NO_ATOMIC_RENAME     
    QUOTA                           QUOTA                
    RIGHTS=kxte                     ---
    SASL-IR                         ---
    SORT                            SORT                 
    SORT=MODSEQ                     ---
    STARTTLS                        ---
    THREAD=ORDEREDSUBJECT           THREAD=ORDEREDSUBJECT
    THREAD=REFERENCES               THREAD=REFERENCES    
    UIDPLUS                         UIDPLUS              
    UNSELECT                        UNSELECT             
    URLAUTH                         ---
    X-NETSCAPE                      X-NETSCAPE
(Correction of Comment #3)
Listing in Comment #3 was incorrect(some lost by my edit miss). Sorry for spam.

CAPABILITY response (corrected and shortened)
  - mail.sproing.at   (Cyrus IMAP4 v2.3.8-Sproing-5)  
  - imap.univie.ac.at (Cyrus IMAP4 Murder v2.2.13)
 (Both of mail.sproing.at and imap.univie.ac.at)
   IMAP4 IMAP4rev1
   ACL ANNOTATEMORE BINARY CHILDREN ID IDLE LITERAL+ MAILBOX-REFERRALS
   MULTIAPPEND NAMESPACE NO_ATOMIC_RENAME QUOTA SORT STARTTLS
   THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDPLUS UNSELECT X-NETSCAPE
 (imap.univie.ac.at only)
   none
 (mail.sproing.at only)
   AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN CATENATE CONDSTORE LIST-SUBSCRIBED
   LISTEXT RIGHTS=kxte SASL-IR SORT=MODSEQ URLAUTH
(In reply to comment #0)
> Build Identifier: Thunderbird 2.0.0.0 (X11/20070326)
> But working on cyrus 2.3.8 with RFC 4314 ACLs makes it impossible to delete
> mails since the "Delete Message" context menu is greyed out.
>(snip)
> It was no problem with 1.5.0.x to work on cyrus 2.3.x releases with rfc 4314
> ACLs so far.

Can you test with latest-trunk nightly(under development Tb 3.0)?
(Test with new profile/account of mail.sproing.at only is recommended.)                 
I downloaded
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0a1.en-US.linux-i686.tar.bz2

I created a new unix account with clean profile, but no difference. tb3.0a1(timestamp 18-Apr-2007 03:48) wont let me delete mails on cyrus 2.3.x, too.

Do you need additional log files? I can provide you an IMAP Account at mail.sproing.at for debugging purposes, too. If that's an option please contact me directly.
(In reply to comment #6)
> I created a new unix account with clean profile, but no difference. tb3.0a1
> (timestamp 18-Apr-2007 03:48) wont let me delete mails on cyrus 2.3.x, too.
Thanks for your quick test and good data to analyze problem.

> Do you need additional log files?
Sorry but I'm not a developer, then I can't analyze your problem, but I think problem is clear, cyrus 2.3.8 with rfc 4314 ACLs doesn't work after Tb 2.0 or later. Please wait for analysis by developers. I think sufficient data for initial analysis has been provided by you.
I did some further research and it seems that it's the fault from cyrus 2.3.x since RFC 4314 requires the server to return "c" and "d" flags for compatibility.

RFC4313: "When any of the "delete" member rights is set in a list of rights,
   the server MUST also include the "d" right when returning the list in
   a MYRIGHTS or ACL response.  This is to enable older clients
   conforming to RFC 2086 to work with newer servers. (*)"

and "(*)  Clients conforming to this document MUST ignore the virtual "d"
        and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses."

cyrus does this for "MYRIGHTS" eg.:
-1262507120[c59ae28]: c4b60a0:mail.sproing.at:S-INBOX:CreateNewLineFromSocket: * MYRIGHTS INBOX lrswipkxtecda

but cyrus fails to return them on "GETACL" eg.:
-1262507120[c59ae28]: c4b60a0:mail.sproing.at:S-INBOX:CreateNewLineFromSocket: * ACL INBOX mashgmx lrswipkxtea

If you confirm my thoughts I'll open a bugreport at cyrus bugzilla and this bug can be closed.
Wolfgang, you may be right. It's certainly worth asking the cyrus folks. I would think myrights would override, though.


I've found the part in cyrus source already and will try to fix it tonight. I'll report back if I'm successfull proofing my thoughts;-)
OK, I think this is just because we don't treat 't' as meaning delete is allowed - we still just look at 'd'. I would think for compatibility, the server should also return 'd' in the acl, but if we parsed 't' correctly, that would fix it as well, I think.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8)
> it's the fault from cyrus 2.3.x

(Off-topic)
Another fault(or not-so-good-setup) maybe exists on mail.sproing.at, although I believe it has no relation to this bug's issue.
Following is a page found by Google search with "RIGHTS=kxte Cyrus" (third one when my search).
  http://www.mail-archive.com/cyrus-devel@lists.andrew.cmu.edu/msg00037.html
This page says "LIST-EXTENDED is added and is default in future", but there is no LIST-EXTENDED in CAPABILITY response from mail.sproing.at in your log (old LISTEXT is found). 
Let mail.sproing.at know about this.
Attached patch possible fix — — Splinter Review 
treat 't' as delete rights in folder...

I'm going to file a separate bug for fully supporting RFC 4314
Assignee: mscott → bienvenu
Status: NEW → ASSIGNED
Attachment #262146 - Flags: superreview?(mscott)
Attachment #262146 - Flags: superreview?(mscott) → superreview+
Blocks: 378047
Ok, I patched cyrus to provide the right (full) answer to "getacl" as required by RFC 4314 and it works like a charm now with Thunderbird 2.x+!

. getacl INBOX
* ACL INBOX mash lrswipkxtecda anyone p
. OK Completed
. myrights INBOX
* MYRIGHTS INBOX lrswipkxtecda

So I'll report this issue to the cyrus devs, too.
(In reply to comment #12)
> (Off-topic)
> Another fault(or not-so-good-setup) maybe exists on mail.sproing.at, although I
> believe it has no relation to this bug's issue.
> Following is a page found by Google search with "RIGHTS=kxte Cyrus" (third one
> when my search).
>   http://www.mail-archive.com/cyrus-devel@lists.andrew.cmu.edu/msg00037.html
> This page says "LIST-EXTENDED is added and is default in future", but there is
> no LIST-EXTENDED in CAPABILITY response from mail.sproing.at in your log (old
> LISTEXT is found). 

Hmmm, this one is addressed in
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2875
but it seems a major feature enhancement and was put in cyrus 2.4 tree.

> Let mail.sproing.at know about this.
I'm the bofh at mail.sproing.at ;-)

I've checked my client fix in on the trunk.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment on attachment 262146 [details] [diff] [review]
possible fix

might be nice to get this for the next . release
Attachment #262146 - Flags: approval1.8.1.4?
Comment on attachment 262146 [details] [diff] [review]
possible fix

approved for 1.8.1.4, a=dveditz for release-drivers
Attachment #262146 - Flags: approval1.8.1.4? → approval1.8.1.4+
client-side fix landed on the 2.0 branch - if you want to, you can try a nightly 2.0 build from tomorrow to see if this fixes it for you...
Keywords: fixed1.8.1.4
sorry, can't test anymore since cyrus 2.3.8 wont let me set "invalid" ACLs and I've already fixed/reset them all.
David, so it should be fixed when downloaded now? Mine is still not working (cyrus 2.3.8), however my delete was initially working when I installed at the beginning of May. I was moving some folders around and making a couple other changes in thunderbird, not sure exactly what triggered it because it took a while to notice but something caused my delete to no longer work. It must have made a change in imap because I tried installing thunderbird on other machines and my delete just will not work, except in thunderbird 1.5.
(In reply to comment #24)
> Mine is still not working (cyrus 2.3.8), however my delete was initially working
> when I installed at the beginning of May.
> my delete just will not work, except in thunderbird 1.5.

To Sean:
Did you get IMAP protocol log and confirm that your problem is this bug?
Trunk? 1.8 build? Which build worked at the beginning of May? Which build doesn't work currently? One in next library?
 http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
 http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/
(In reply to comment #25)
> (In reply to comment #24)
> > Mine is still not working (cyrus 2.3.8), however my delete was initially working
> > when I installed at the beginning of May.
> > my delete just will not work, except in thunderbird 1.5.
> 
> To Sean:
> Did you get IMAP protocol log and confirm that your problem is this bug?
> Trunk? 1.8 build? Which build worked at the beginning of May? Which build
> doesn't work currently? One in next library?
>  http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
>  http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/
> 

Sorry I don't have time to read all of this but I think it may have been a different bug. Now my delete button is working for both versions listed above and the stable release that wasn't working previously. I wasn't trying any of the builds before, I was using the stable release from the main site at the beginning of May. Thunderbird 2.0 did trigger a change with Thunderbird to imap that caused the delete to no longer function, regardless of trying the stable 2.0 on other machines. It was resolved by installing 1.5 and using my box, it undid whatever changes 2.0 made to my imap box. Now it works all around, as it did for almost a month now with 2.0. If I can figure out what caused that I'll let you guys know, wierd is all I can conclude at this point.
Running 2.0.0.5, bug is still there here is example how reproduce it.
Enabled move Junk messages when marked as Junk, TB tried to move message to junk but it doesn't have such rights.
I'm running Thunderbird-2.0.0.6 and using Courier-IMAP-4.1.3 (not Cyrus) and have the same problem:

I've set ACL rights to "eilrstw" to some-folder, which relatively means that I should be able to mark messages from some-folder as deleted, but I should not be able to delete some-folder itself.


If I select a message in some-folder, the DEL key doesn't respond and the delete-button in the context-menu is grayed out. It doesn't matter if I configure the delete-button to "Move message to trash" or "Mark as deleted".

But, when I configure the delete-button to "Mark as deleted", and I manually move the message from some-folder to the trashcan, the message is marked as deleted! So the server correctly allows me to mark the message from some-folder as deleted (as the 't' in the ACL describes).


When I select some-folder itself, the delete-button is not grayed out. When I press it the folder disappears. I don't think this should happen.

But when I take a look at the subscribe-list, some-folder is still there. I can subscribe to it, and all is ok. So the server correctly prevents me from deleting some-folder (as lack of 'x' in the ACL describes).
Addition:

I see I was incorrect about Thunderbird-2.0.0.6 and the problem with deleting folders. What I reported was tested with Thunderbird-1.5.0.12.
When I try to delete some-folder (ACL "eilrstw"), Thunderbird-2.0.0.6 correctly tells me access is denied because ACL 'x' is missing.
I'm extremely sorry for misreporting that :(


I did discover something else:
- Like I said, when including the ACL 't' I can't mark messages as deleted.
- If I include the ACL 'x' I can't mark messages as deleted (as expected).
- But if I include them both (ACL "xt") I *can* mark messages deleted.

This makes me think Thunderbird-2.0.0.6 needs both 'x' and 't' in order to allow the deletion of messages. This isn't correct, only 't' should be enough.


PS: I've also tested this with Thunderbird-3.0a1pre, same results as Thunderbird-2.0.0.6
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: