Open Bug 160291 Opened 22 years ago Updated 2 years ago

inconsistant ACLs with or without 'IMAP Server Directory' setting

Categories

(MailNews Core :: Networking: IMAP, defect)

defect

Tracking

(Not tracked)

People

(Reporter: Henry.Jia, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [patchlove])

Attachments

(3 files, 1 obsolete file)

From Michael Klose's comment in bug 105385 (http://bugzilla.mozilla.org/show_bug.cgi?id=105385#c21). I am seeing a slight ACL issue with this. (Fastmail.fm cyrus account with ACLs enabled) When NOT USEING a server directory, clicking on properties of the folder is telling me: "This is a personal mail folder. It has been shared. You have the following permissions: Read, Write, Insert (Copy Into), Set Read/Unread, Delete Messages, Create Subfolder, Post" When USEING a server directory('INBOX'), I get the message for the exact same folder: "This is a personal mailfolder. It is not shared". "You have the following permissions: Full control". When logging into the IMAP account with TELNET, and doing a GETACL on the folder, I see that I and admin have these priveledges. I just think it is strange that it is showing me two different things for the same folder. I can also verify this issue.
Add Michael Klose to CC list.
Please change summary to "inconstistant ACLs with and without IMAP Server directory" Thanks:-) (it should include the word ACL)
Done. :)
Summary: inconsistant between with or without 'IMAP Server Directory' setting → inconsistant ACLs with or without 'IMAP Server Directory' setting
How about attaching a protocol log? I believe we just report the acl as given to us by the server (using MYRIGHTS)
Attached image snapshot for this bug (deleted) —
Blocks: 160644
Let me take care of this one. Add mscott to the CC list.
Assignee: mscott → Henry.Jia
Henry, how about attaching an imap protocol log? Thx.
Attached file protocol log (deleted) —
Sorry, David. I misunderstood your meaning of comment #4. I thought you want the log of server side. Here is the log from client side. One more thing is that, after we use 'IMAP server directory' and then don't use it, mozilla still tells us the folder is fully controlled.
If a folder has personal namespace, mozilla uses 'getacl' to get the control list. If the folder has share or public namespace, mozilla uses 'myrights' to get the control list.
Attached file rfc 2086 - the related protocol (deleted) —
My test result of this bug in detail. 1.Using 'getacl' and 'myrights' to get the acl of a folder, the results is defferent: a getacl inbox.y * ACL inbox.y philipzhao lrswipcd admin lrswipcda anyone p a OK Completed a myrights inbox.y * MYRIGHTS inbox.y lrswipcda a OK Completed 2.If the folder you test is in the personal namespace with the prefix of 'INBOX', mozilla will always use 'getacl' to get the acl whatever you set the IMAP server diretory to 'INBOX'. 3.First pls set the IMAP server directory to 'INBOX'. Pls press right button of your mouse, look the properties of the folder(for exam, INBOX.y), mozilla will tell you: "This is a personal mailfolder. It is not shared". "You have the following permissions: Full control". 4.Now pls clean the set of IMAP server directory and *don't* press left button of your mouse on any of the folders! Just press *right* button of your mouse and see the properties of folder INBOX.y, we will see still: "This is a personal mailfolder. It is not shared". "You have the following permissions: Full control". 5.Now please press left button of your mouse on folder INBOX.y. Then check the properties of this folder. we will see: "This is a personal mail folder. It has been shared. You have the following permissions: Read, Write, Insert (Copy Into), Set Read/Unread, Delete Messages, Create Subfolder, Post" 6.Insteadly, when we first without IMAP server directory set 'INBOX' and with the properties seen like 'a shared folder...', and next set the IMAP server directory, and never need us to press left button on the folder, mozilla will change the folder's acls(the show of the properties of the folder will be 'it is not shared...'). This performance means when we set IMAP server directory to 'INBOX' or others, mozilla will check and change the acls of all it's folder(except 'INBOX') automaticly.
The key of this bug is still we should use cononical formated mailbox name when we set IMAP server directory to 'INBOX'.
Because of any folder's acl is like: a getacl inbox.y * ACL inbox.y philipzhao lrswipcd admin lrswipcda anyone p a OK Completed So it's shared and the properties show "This is a personal mail folder. It has been shared. You have the following permissions: Read, Write, Insert (Copy Into), Set Read/Unread, Delete Messages, Create Subfolder, Post" is right.
Attached patch patch for test (obsolete) (deleted) — Splinter Review
This patch works on my cyrus server, letting the properties consistant whether or not you set the IMAP server directory. The show of properties of a folder will be : "This is a personal mail folder. It has been shared. You have the following permissions: Read, Write, Insert (Copy Into), Set Read/Unread, Delete Messages, Create Subfolder, Post"
QA Contact: huang → gchan
attachment 106880 [details] [diff] [review] seems ok for me. Please r=?&sr=?. Thanks!
What's happening with the patch?
Attachment #106880 - Flags: review?(ere)
Comment on attachment 106880 [details] [diff] [review] patch for test Sorry, I don't have ACL capable server available atm.
Attachment #106880 - Flags: review?(ere)
Product: MailNews → Core
Product: Core → MailNews Core
Assignee: Henry.Jia → nobody
Keywords: helpwanted
QA Contact: grylchan → networking.imap
Whiteboard: [patchlove]
Comment on attachment 106880 [details] [diff] [review] patch for test Patch has bitrotted. $ patch -p0 --dry-run < ~/Desktop/tbTestPatches/160291.diff patching file nsImapProtocol.cpp Hunk #1 succeeded at 97 with fuzz 2 (offset 7 lines). patch unexpectedly ends in middle of line Hunk #2 FAILED at 3982. 1 out of 2 hunks FAILED -- saving rejects to file nsImapProtocol.cpp.rej
Attachment #106880 - Attachment is obsolete: true
Philip, any chance of an updated patch?
(In reply to comment #19) > Philip, any chance of an updated patch? Just noticed he's gone. https://bugzilla.mozilla.org/show_bug.cgi?id=166603#c55
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: