1595730 - Write/change actions on Sogo shared mailbox folders fail "Permission denied [NOPERM]

Status: RESOLVED INVALID

(MailNews Core :: Networking: IMAP, defect)

Description

[marco.jaeger]

Attachment: BUG1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Creating via SOGo (iRedMail [Dovecot]) a shared folder access works fine. Every permission is given to the User. Trying now to move a mail from Folder1 to Folder2 will not work. Message from ThunderBird: Permission denied [NOPERM].

The same issue with the same message happend when you try to delete a mail.

Example:
You have 2 folder called Folder1 and Folder2 and you want to move a mail from Folder1 to Folder2. You have every permission on both folders (see Attachment "Bug1") that you can give in SOGo. Now when you try to move you will get instantly a message called: Permission denied [NOPERM] (0.001 + 0.000 sec.)
How do i know that this is a Thunderbird Problem?
Trying to move the same mail from Folder1 to Folder2 with Outlook or the SOGo Web GUI works fine.

Actual results:

The mail will not be moved and you get a NOPERM Permission denied message. Same issue when trying to delete a mail.

Expected results:

If the permission is given to the people they should be able to move mails in shared Mailboxes without any kind of problem.

Comment 1

[Wayne Mery (:wsmwk)]

How did this problem start - when you updated from version 60 to 68? Or from some other version?

Comment 2

[marco.jaeger]

The problem is also in the Version 60. I checked if Thunderbird V68 fixed the issue but with V60 or V68 it will not work.

Comment 3

[marco.jaeger]

How it start:

We changed our mail service from kolab to SOGo. With kolab there was no problem. But with SOGo the problem appears. I also created a Bug report at SOGo Bug Tracker and they said that this is a Thunderbird issue because its working with other email programs.

Comment 4

[Wayne Mery (:wsmwk)]

I find it hard to believe Sogo can't give better guidance given that a) they surely have tons of Thunderbird users and b) you say this also happens in version 60 and so c) one would think they would have encountered your issue in the past. Do you have a publicly viewable URL to the sogo ticket?

I don't know where to begin and I find nothing in bugzilla https://mzl.la/34Uw6Da. Perhpas Gene has an idea.

Reference https://sogo.nu/files/docs/SOGoMozillaThunderbirdConfigurationGuide.html

Comment 5

[marco.jaeger]

So i have the a link to the Ticket from SOGo: https://sogo.nu/bugs/view.php?id=4831
This Ticket is closed because of the Administrator "ludovic". He said this is a general Thunderbird question. So if SOGo is not the problem we only have Thunderbird (Client) and IRedMail but as I said, with a other email program it works.

I know the manuel from SOGo and we also installed the SOGo Plugins. Everything with SOGo Connector and SOGo Integrator works.

Comment 6

[gene smith]

Not familiar with sogo or iredmail. But do know about dovecot (used by iredmail?). Anyhow, need to see the IMAP:5 log that is recorded when the copy between shared folders with the permission error occurs. See https://wiki.mozilla.org/MailNews:Logging and record and attach the resulting log using the link above. Also, describe in detail what actions were done in TB while recording the log.

Another option, if possible, is to provide me with a test accounts on your server that will allow me to locally see and debug the problem. If possible, this is usually the most effective way to troubleshoot these kind of issues.
Thanks.

Comment 7

[marco.jaeger]

So i added a imap.log as attachment. When you open Notepad++ you can see in Line 8624 till 8637 this Permission Denied Error.

What I do: There are 2 Folders, Junk and Trash. I try to move a mail from Junk to Trash and then this Error appears.

Comment 8

[marco.jaeger]

Attachment: imap.log

Comment 9

[gene smith]

I don't see a reason for this in the log. So you are moving a messages from a shared user's Junk to their Trash. The error I see is coming from the server (dovecot) when tb attempts to do the imap move. There are also ACL rights shown in the log and in the log and there seems to be full permission to do almost anything (copy, delete etc). I don't see tb trying to set or change the access rights on any folder.
Can you copy (instead of move) a message from shared Junk to shared Trash?
Can you see and read all the emails in the shared user's folders?
Can you delete a message from any shared user's folder? (I think you already said you can't.)

I have a dovecot server set up with a shared user for tb testing. I will run it later today and try to test your issue. (I don't have any of the higher level application you mention like sogo, just dovecot. Tb only communicates with imap server and not the other apps.)

I just looked closer in your log at the permission list returned by the shared junk and trash. It appears that the "expunge" permission "e" is not included. This may be why the NOPERM error response is occurring. The imap move command requests to "move" the message to shared trash but since there is no expunge permission, it is blocked by the server. Expunge occurs after a message is moved so that the message in the source folder is completely removed and not just marked with \deleted flag. You can test this by attempting to copy (instead of move) the message from the shared Junk to the shared Trash. If that works, you can then delete the message from the source folder and then compact the folder. If you see an error on compact, then that's the problem.

It may be possible to add the "e" permission in tb using the right-click folder properties under sharing tab, but not sure about this. Since the administrative "a" is set it might be possible. (I will check this later.)

Comment 10

[gene smith]

I duplicated what you see with my local dovecot server. Setting up a shared folder, if I remove the "e" permission I see exactly the same error you see and the imap move does not work. With the "e" not present, imap copy does work since no expunge or delete occurs, unlike with imap move.

It may be possible to add the "e" permission in tb using the right-click folder properties under sharing tab, but not sure about this. Since the administrative "a" is set it might be possible. (I will check this later.)

I checked and this is not possible; tb doesn't support setting the acl permissions, such as adding "e". I don't know why your high level applications don't set the "e" permission. I guess you will need to contact their support to find out how to fix the problem so the "e" is included. But it may be possible to fix the problem by communicating directly with dovecot using telnet or openssl command line. To add the "e" it is possible to do something like this:

# Log into account providing the shared folder. Use openssl and not telnet if server uses SSL/TLS which it probably does.
telenet <yourServer> <port>
. login <username> <password>
. setacl <folderPathToShare> <userNameToShareWith> +e

This is how I did it with only dovecot. You can see this explained also on the dovecot wiki https://wiki.dovecot.org/SharedMailboxes/Shared. More details are in this rfc: https://www.rfc-editor.org/rfc/rfc4314.html

Just to be clear, from the log the problem is this:

2019-11-14 08:54:25.063000 UTC - [22020:Unnamed thread 000001AFDAAAEC00]: I/IMAP 000001AFDD75A000:imap.mmlab.de:S-Shared/[e-mail]/Junk:SendData: 6 myrights "Shared/[e-mail]/Junk"
2019-11-14 08:54:25.073000 UTC - [22020:Unnamed thread 000001AFDAAAEC00]: D/IMAP ReadNextLine [stream=000001AFDA4D1E00 nb=61 needmore=0]
2019-11-14 08:54:25.073000 UTC - [22020:Unnamed thread 000001AFDAAAEC00]: I/IMAP 000001AFDD75A000:imap.mmlab.de:S-Shared/[e-mail]/Junk:CreateNewLineFromSocket: * MYRIGHTS Shared/[e-mail]/Junk lrwstipkacd
2019-11-14 08:54:25.073000 UTC - [22020:Unnamed thread 000001AFDAAAEC00]: D/IMAP ReadNextLine [stream=000001AFDA4D1E00 nb=47 needmore=0]
2019-11-14 08:54:25.073000 UTC - [22020:Unnamed thread 000001AFDAAAEC00]: I/IMAP 000001AFDD75A000:imap.mmlab.de:S-Shared/[e-mail]/Junk:CreateNewLineFromSocket: 6 OK Myrights completed (0.001 + 0.000 secs).

This shows the permission (rights) returned by Junk folder. The same permission is returned by Trash. The permission string is lrwstipkacd and it needs to be lrwstipekacd for all folder to support expunge (needed for move command to work).

Comment 11

[marco.jaeger]

Hi gene smith,

first thank you very much. I connectet to our dovecot Server via ssh and then connected with openssl to our dovecot.

After that i run the command: "a setacl Junk <myEmail> +e" and "a setacl Trash <myEmail> +e"
This is the result: a OK Setacl complete (0.107 + 0.000 + 0.106 secs).

Then i check if the move works and it worked. I dont know why this permission is missing and why Outlook users have not this issue.
Now still one question. How can I fix that problem without adding the permission everytime for a shared folder. Is there a "mass command" like
"a setacl <allFolders> <allUsers> +e"

And a another question: Is this a SOGo Issue or from IRedMail or Dovecot? Maybe i can create a bug ticket on their Bug Tracker and fix this issue.

Comment 12

[gene smith]

I dont know why this permission is missing and why Outlook users have not this issue.

I also wondered why outlook worked for the "move" given the lack of "e" permission. I don't have outlook so I can't tell for sure, but it is possible that outlook doesn't use imap move but "simulates" move by doing approximately these step:

copy junkMsg from junk to trash
mark junkMsg in junk as \deleted

This would avoid the need for an expunge to occur. This is what tb does too but only when "MOVE" capability is not supported by the server so the move is simulated when requested.
I suspect that SOGo or IRedMail (don't know which one control the "e" permission) leave off the "e" for shared folders so that non-owners using the folder can still "delete" message but can't really permanently delete the message using outlook's command to expunge (compact) the folder. Only the shared folders true owner can expunge the folder. But just a guess.

Now still one question. How can I fix that problem without adding the permission everytime for a shared folder. Is there a "mass command" like
"a setacl <allFolders> <allUsers> +e"

I don't see anything like a wildcard for affecting all folders and users in the imap ACL commands.

And a another question: Is this a SOGo Issue or from IRedMail or Dovecot? Maybe i can create a bug ticket on their Bug Tracker and fix this issue.

I'm not sure on this. If SOGo is where the ACLs are globally set, I would say they are the problem (they need to optionally include the "e" flag). Looking at SOGo and iRedMail docs, I don't see anything about setting imap ACLs via a gui. Working with just raw dovecot, I don't see a way to globally set ACLs either. But I'm no expert on any of these (and until this bug, never heard of iRedmail or SOGo!).

A possible work around is to configure dovecot to not support MOVE capability. This will cause tb to simulate any move request as described above. However, when simulating MOVE using imap copy and mark as deleted, when the UIDPLUS cabability is also available, tb then does a UID expunge on the message marked as deleted (not the folder based standard imap expunge). This will also cause a NOPERM. So you may also need to configure dovecot to not support UIDPLUS capability (it does by default). Of course, this is just a possible workaround that I haven't actually tested.

Comment 13

[marco.jaeger]

How can we disable or deactivate UIDPLUS and has it any changes to our current usage? And after disable it will the move work like in Outlook?

Comment 14

[gene smith]

I'm assuming you have admin control of the dovecot server. If so, you can set the CAPABILITY response string that dovecot sends to clients using /etc/dovecot/conf_d/20-imap.conf configuration file. Currently, based on your tb log, dovecot sends this after-login capability response:

IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY SPECIAL-USE QUOTA ACL RIGHTS=texk

So 20-imap.conf you can set the variable imap_capability to exclude MOVE and UIDPLUS:

imap_capability = IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY SNIPPET=FUZZY SPECIAL-USE QUOTA ACL RIGHTS=texk

There is a "+" feature to add items but I don't think there is a "-" feature, so doing just this won't work (the last time I tried it):

imap_capability = -MOVE UIDPLUS

Anyhow, probably need to do this with dovecot shutdown then restart dovecot when you have 20-imap.conf changed. You can record a tb log to make sure the after login capability sent by dovecot changes to exclude MOVE and UIDPLUS.

Again, I'm no expert on this and only use dovecot informally for testing tb issues. I also think the "correct" solution is for the higher level apps (sogo etc) to handle setting the imap acl for shared folder to include the "e".

I don't think disabling UIDPLUS and MOVE will break anything but be careful and keep a 20-imap.conf backup if you need to go back to default dovecot behavior.

Comment 15

[Wayne Mery (:wsmwk)]

Invalid (or wontfix) per comment 14