170597 - IMAP folder permissions show ACL for wrong user

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Kevin P. Fleming]

I am using Mozilla build of 9/24/02, although problem began when I install 1.2a.
My IMAP server is Cyrus IMAPD 2.1.5. I have two accounts on this server, with
many folders and subfolders each. Everything works fine, except for two folders
on each account.

These two folders on each account, in addition to having "full control"
permissions for the mailbox owner, have "post" rights for "anyone". This is so
that I can have messages posted directly into those folders.

When these folders are displayed Mozilla, and a message is selected, the
"delete" menu/toolbar item is grayed out. If I right-click on the folder and
look at properties/sharing, Mozilla says I only have post rights. This is
obviously not correct.

Interestingly, I _can_ move messages out of these folders into other folders and
delete them there. I can (apparently) reproduce this at will, since I've tried
the 1.2 alpha and two nightly builds, and removed/readded my IMAP accounts with
no success.

Comment 1

[Antti Boman]

I confirm this behaviour, and with Cyrus and mailboxes set the same way (my
username with full control, 'anyone' with only 'post' on). My situation is even
worse, as Inbox is the only box with Full Control, all the other ones have only
Post permission. 1.1b worked ok, this was introduced in 1.2a. And now confirming
for 1.2b, too.

I also tried moving messages from a folder that Mozilla claims to be 'post'
only, and it worked. Also, I deleted the account and added it again, but no change.

I'll try to see the source code if I could find something there. Obviously I
won't, as I haven't ever checked the sources out.

Comment 2

[Antti Boman]

A quick remark: I can also delete the folders which are 'post' only.

Comment 3

[Antti Boman]

Okay, I tried reading the sources, and this is what I found. It may not be of
help, and I'm not sure if I got it right. I also couldn't create a patch, as I
don't know the base well enough. Anyway, step by step:

#1
http://lxr.mozilla.org/mozilla/source/mailnews/imap/src/nsImapMailFolder.h#137
tells that you shouldn't use GetCanUser-functions, but use GetCanI-functions
instead. It seems GetDoIHaveFullRightsForFolder() uses GetCanI-functions.

#2
nsMsgIMAPFolderACL::GetCanIAdministerFolder() consists only of:

return GetFlagSetInRightsForUser(nsnull, 'a', PR_TRUE);

Here I want to point out we're not sending the user name, but nsnull, as intended.

#3
PRBool nsMsgIMAPFolderACL::GetFlagSetInRightsForUser(const char *userName, char
flag, PRBool defaultIfNotFound) gets the flags by calling:

const char *flags = GetRightsStringForUser(userName);

so userName is nsnull here, too. That's ok.

#4
const char *nsMsgIMAPFolderACL::GetRightsStringForUser(const char *inUserName)
starts with:

if (!inUserName)
   return nsnull;

#5
So, flags will be nsnull, and GetRightsStringForUser falls to using user
'anyone', and things get screwed up:

if (!flags)
   {
     const char *anyoneFlags = GetRightsStringForUser(IMAP_ACL_ANYONE_STRING);


Did I miss something or solve the problem? I wish I hit the second one.

Comment 4

[Antti Boman]

I checked out and found that Mozilla 1.0 (which didn't have this problem) didn't
include the thing described in part #4 of the previous message, ie. it doesn't
check if inUserName is non-zero.

Now I'll start betting on how long it takes for someone to find out this
monologue I'm pulling here. Or then I just continue to teach myself how Mozilla
works, so that I could drop patches instead of speculations.

Comment 5

[Marko Macek]

My coworker here has this problem with moz 1.2b. 

On the re-start of mozilla all is fine, but after some time only post privilege
is shown on some folders.

Is this bug a dupe or should it be confirmed?

Comment 6

[Antti Boman]

I believe it's a dupe, as I experience the same problem. If I'm correct, the
permissions show ok up until Mozilla checks for new mail in the folder.

For example, if I start Mozilla, and check folder permissions without entering
it, all's ok. After opening the folder I see only Post permissions. And that'll
stay until I restart the whole program.

Comment 7

[Marko Macek]

I can't find a confirmed dupe, so confirming this.

Comment 8

[Antti Boman]

As this bug is a blocker for me, ie. I haven't been able to upgrade my Mozilla
after version 1.1, I'm willing to help out testing when someone gets to
resolving this. I tried the nightly build yesterday (11th November 2002), and
the problem was still around.

I'm not demanding, just giving a hand.

Comment 9

[Antti Boman]

Sorry about spamming, but I forgot to add that I can arrange a username for
testing on our Cyrus IMAP server.

Comment 10

[David Lampert]

As a workaround, you can drag that "undeleteable" message to the LOCAL trash
folder and it marks it for deletion on the IMAP server.

I use fastmail.fm as my IMAP server.

Comment 11

[Antti Boman]

> As a workaround, you can drag that "undeleteable" message to the LOCAL trash
folder and it marks it for deletion on the IMAP server.

But I cannot even see the list of mail in some folders, which makes it fairly
hard to delete it :) That's mainly the problem I cannot switch from 1.1.

Comment 12

[Nathaniel]

I can confirm this bug on Win98se as well, so it may need to change to all OS.
this is definitely major/critical for those of us using IMAP.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

This sounds like David might have some ideas here, reassigning...

Comment 14

[David :Bienvenu]

sure, I could use a test account to try this out on, thx. Just e-mail me directly.

Comment 15

[David :Bienvenu]

Attachment: proposed fix

Comment 16

[David :Bienvenu]

Comment on attachment 107659 [details] [diff] [review]
proposed fix

this has r/sr=sspitzer

Comment 17

[David :Bienvenu]

Attachment: proposed fix

last one was wrong diff file

Comment 18

[David :Bienvenu]

Comment on attachment 107660 [details] [diff] [review]
proposed fix

r/sr=sspitzer

Comment 19

[David :Bienvenu]

let me know what issues remain, if any, thx!

Comment 20

[Antti Boman]

I confirm the fix works for me. No problems at all. Thanks, David.

Comment 21

[David :Bienvenu]

*** Bug 182634 has been marked as a duplicate of this bug. ***

Comment 22

[David :Bienvenu]

*** Bug 182873 has been marked as a duplicate of this bug. ***

Comment 23

[David :Bienvenu]

*** Bug 183440 has been marked as a duplicate of this bug. ***

Comment 24

[David :Bienvenu]

*** Bug 183727 has been marked as a duplicate of this bug. ***

Comment 25

[Matthias Versen [:Matti]]

*** Bug 184292 has been marked as a duplicate of this bug. ***

Comment 26

[David :Bienvenu]

*** Bug 185205 has been marked as a duplicate of this bug. ***

Comment 27

[David :Bienvenu]

*** Bug 185405 has been marked as a duplicate of this bug. ***

Comment 28

[Matthias Versen [:Matti]]

*** Bug 189674 has been marked as a duplicate of this bug. ***

Comment 29

[Taija Pirhonen]

I can still repro the problem.

I'm using mozilla version 1.4.1 and my mailserver is Cyrus IMAP4 1.6.25. My ACL
is like follows:

anyone p
<userid> lrswpicda (list, read, save, write, post, insert, create, delete, admin)
                   
I can't delete individual mails and my folders say (properties | sharing) that I
have only right to post.

However, when I first only (without going in) right click the folder it says
that I have Full control (propably repro to bug 160291?)

Comment 30

[David :Bienvenu]

please try a 1.5 or 1.6 final build

Comment 31

[Taija Pirhonen]

I can't repro the bug on Mozilla 1.5 because it doesn't show the other folders
at all, only my inbox (has anyone made report about this?). If I switch back to
1.4.1 the other folders can be seen again.

Comment 32

[Taija Pirhonen]

Attachment: imap-log file

Attached is Mozilla 1.5 imap-log file that was collected when it didn't show
any other folder except inbox (if that is of any use). I also tried to
subscribe the other folders but that didn't help.

I tried also 1.6b (didn't find 1.6 final) and it seems to work fine (at least
on these bug items).

Comment 33

[David :Bienvenu]

ok, yeah, this is fixed in 1.6b (which is pretty close to 1.6 final, which
should be out soon). Thx.