The following issue has been RESOLVED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=298 ====================================================================== Reported By: windowsrefund Assigned To: paul ====================================================================== Project: DBMail Issue ID: 298 Category: IMAP daemon Reproducibility: always Severity: minor Priority: low Status: resolved target: Resolution: fixed Fixed in Version: SVN Trunk ====================================================================== Date Submitted: 04-Feb-06 22:32 CET Last Modified: 09-Sep-06 11:05 CEST ====================================================================== Summary: Read-only flag on mailboxes must be respected Description: Note: This problem has been reproduced on 2.0.9
Mailboxes 4 levels deep that have had their 'permission' attribute (dbmail_mailboxes.permission) set to a value of 1 can be deleted. All mail stored in this mailbox will also be deleted, effectively bypassing the read-only attribute of the mailbox. ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000347 Parent mailboxes are not created when a... ====================================================================== ---------------------------------------------------------------------- windowsrefund - 04-Feb-06 22:58 ---------------------------------------------------------------------- Please disregard the original verison information in the description. 2.0.9 is currently suffering from LIST problems so this problem affects 2.0.7. I will test 2.0.8 shortly ---------------------------------------------------------------------- windowsrefund - 04-Feb-06 23:42 ---------------------------------------------------------------------- Both 2.0.7 and 2.0.8 suffer from this problem. TRACE LEVEL 5 logs attached. ---------------------------------------------------------------------- dgjackli - 10-Feb-06 02:22 ---------------------------------------------------------------------- ---------------------------------------------------------------------- paul - 30-Apr-06 18:14 ---------------------------------------------------------------------- All write actions on mailboxes (db_delete_mailbox, db_imap_append_msg, db_removemsg) now first check the permission flag (db.c, mailbox_is_writable). So message insertion by the MTA will still succeed which in my view seems the right thing to do. Feel free to reopen this bug if you consider this an omission. ---------------------------------------------------------------------- windowsrefund - 19-May-06 18:08 ---------------------------------------------------------------------- This problem can be reproduced on SVN 2114. ---------------------------------------------------------------------- windowsrefund - 19-May-06 20:59 ---------------------------------------------------------------------- Also reproducible on SVN 2124 My temporary work-arounds are listed here. One for 2.0.x and one for SVN. Please excuse my brute force approach as I am not a developer. http://www.dbmail.org/dokuwiki/doku.php?id=archiving-howto#read-only_mailboxes_can_be_deleted ---------------------------------------------------------------------- paul - 19-May-06 22:57 ---------------------------------------------------------------------- Adam, I fixed this problem in svn-trunk. I've tested the following imap commands: STORE and DELETE. Your patch on the wiki only prevents renaming of a mailbox, and has nothing to do with deleting a mailbox or changing the state of contained messages. I'm not sure whether read-only should prevent renaming. There are possibly still more places in the code that need revisiting so I'm leaving this bug open until we make sure we nailed them all. ---------------------------------------------------------------------- windowsrefund - 20-May-06 00:01 ---------------------------------------------------------------------- Thanks Paul IMO, read-only should certainly prevent attempts to rename. As you know, deleting a mailbox named "foo" just renames it to to Trash/foo. It doesn't actually delete it. Update: I remove the "patches" from the wiki since they appear to blow things up quite nicely. Here's a copy/paste from that page: Although the bug has been addressed as of SVN 2124, the delete attempt still renames the folder so it appears below Trash. For example, INBOX/SubFolder/MyReadOnlyMailbox can be renamed to Trash/MyReadOnlyMailbox. Further attempts to empty the trash will fail but restoring MyReadOnlyMailbox to its proper location would require knowing to recreate INBOX/SubFolder manually. This wouldn’t be a problem if the original folder was not able to be renamed in the first place. If a mailbox is read-only, the only thing a user should be able to do with it is to read its contents. All attempts to do anything but read should fail (this includes rename, delete, move, praise, vulcan-mind-meld, etc). Best, Adam ---------------------------------------------------------------------- aaron - 20-May-06 00:12 ---------------------------------------------------------------------- Adam, the DELETE command (section 6.3.4 of RFC 3501) is definitely there for permanently removing a mailbox. Renaming it to live under the Trash/ hierarchy is an MUA convenience. Mailboxes do not have the mark \deleted/expunge process used for messages, and so my guess is that your MUA is kind of faking this feature. Which MUA are you using? As for renaming, I just messed around on my filesystem a bit, and there's more latitude allowed in manipulating a read only file than I expected. Renaming the file is controlled not by the file's permissions but by the directory's permissions. Makes sense, considering that the directory is just a file with a list of name-to-inode mappings. I guess I just thought of that semantic as being archaic -- I remember back in some old Unices, you could cat a directory and actually read the binary format, but that doesn't work anymore on modern filesystems. That said, I'm not sure which way to go with mailboxes. Should we look at the parent folders's permissions, or is that counterintuitive these days? ---------------------------------------------------------------------- paul - 20-May-06 13:58 ---------------------------------------------------------------------- Aaron, we could simply fix _ic_rename to check for mailbox_is_writable. thing is: what to do about sub-folders marked as read-only where a parent marked read-write is being renamed. Simplest course of action: fail for such children. And if the parent is read-only, refuse to rename and don't even consider renaming children. But I do not want to introduce such a check in db_setmailboxname (yet) as Adam suggests in his patch on the wiki. For now, I'd like to keep things in the imap layer, not introduce new behaviour in such low-level calls in an ad-hoc manner. ---------------------------------------------------------------------- aaron - 20-May-06 20:20 ---------------------------------------------------------------------- Has to be in the imap layer because the db layer knows nothing about the mailbox hierarchy. There must be some spec or public discussion on how this should work... Incidentally, the code to calculate a mailbox hierarchy in imapcommand.c, _ic_create, probably needs to be broken out so that delivery code can also create a hierarchy of mailboxes on demand (bug http://www.dbmail.org/mantis/view.php?id=347). Let's move to the mailing list and discuss how to minimally refactor the code to be effective here. ---------------------------------------------------------------------- aaron - 12-Jun-06 05:49 ---------------------------------------------------------------------- After some more thinking about this, I want to push the mailbox hierarchy stuff into the database layer. If it gets too unweidly, then a new middle layer should be created. So far I've got the creation pushed down to db.c, with ACL checks. Next I need to look at the mailbox delete and rename functions more carefully and generalize the hierarchy loop from the creation code. ---------------------------------------------------------------------- paul - 03-Sep-06 14:03 ---------------------------------------------------------------------- Aaron, does this bug still need fixing? ---------------------------------------------------------------------- aaron - 04-Sep-06 19:50 ---------------------------------------------------------------------- Ok, yes I do have some more work here, I just remembered that I need to make sure we're following RFC 3501 for RENAME and DELETE: With respect to RENAME: The RENAME command changes the name of a mailbox. A tagged OK response is returned only if the mailbox has been renamed. It is an error to attempt to rename from a mailbox name that does not exist or to a mailbox name that already exists. Any error in renaming will return a tagged NO response. If the name has inferior hierarchical names, then the inferior hierarchical names MUST also be renamed. For example, a rename of "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy delimiter character) to "zap/bar". And with respect to DELETE: The DELETE command MUST NOT remove inferior hierarchical names. For example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." is the hierarchy delimiter character), removing "foo" MUST NOT remove "foo.bar". It is an error to attempt to delete a name that has inferior hierarchical names and also has the \Noselect mailbox name attribute (see the description of the LIST response for more details). It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute. The value of the highest-used unique identifier of the deleted mailbox MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail. That last paragraph makes things slightly more complicated. ---------------------------------------------------------------------- aaron - 07-Sep-06 20:30 ---------------------------------------------------------------------- Last comment taken back; the code to do the right things on RENAME and DELETE is present. I'm hazy as to whether RENAME respects the proper ACLs, however. RFC 4314: RENAME - Moving a mailbox from one parent to another requires the "x" right on the mailbox itself and the "k" right for the new parent. For example, if the user wants to rename the mailbox named "A/B/C" to "D/E", the user must have the "x" right for the mailbox "A/B/C" and the "k" right for the mailbox "D". The RENAME command SHOULD NOT change the ACLs on the renamed mailbox and submailboxes. ---------------------------------------------------------------------- aaron - 09-Sep-06 11:05 ---------------------------------------------------------------------- I am satisfied that RENAME is doing the right thing at this time. I've clarified a couple of the ACL checks, and I think everything is OK. I have a few bugs to file with Evolution with respect to its subscription manager, but the responses from DBMail look good :-) Issue History Date Modified Username Field Change ====================================================================== 04-Feb-06 22:32 windowsrefund New Issue 04-Feb-06 22:58 windowsrefund Note Added: 0000983 04-Feb-06 23:41 windowsrefund File Added: mail.dbmail.debug.log 04-Feb-06 23:42 windowsrefund Note Added: 0000984 10-Feb-06 02:22 dgjackli Issue Monitored: aabramov 10-Feb-06 02:22 dgjackli Note Added: 0000999 14-Feb-06 16:38 paul Status new => assigned 14-Feb-06 16:38 paul Assigned To => paul 30-Apr-06 18:14 paul Note Added: 0001146 30-Apr-06 18:14 paul Status assigned => resolved 30-Apr-06 18:14 paul Resolution open => fixed 30-Apr-06 18:14 paul Fixed in Version => SVN Trunk 19-May-06 18:07 windowsrefund Status resolved => feedback 19-May-06 18:07 windowsrefund Resolution fixed => reopened 19-May-06 18:07 windowsrefund Note Added: 0001181 19-May-06 18:07 windowsrefund Issue Monitored: windowsrefund 19-May-06 18:08 windowsrefund Note Edited: 0001181 19-May-06 20:31 windowsrefund Note Added: 0001182 19-May-06 20:46 windowsrefund Note Edited: 0001182 19-May-06 20:59 windowsrefund Note Edited: 0001182 19-May-06 22:57 paul Note Added: 0001183 19-May-06 22:57 paul Priority normal => low 19-May-06 22:57 paul Severity major => minor 19-May-06 22:57 paul Summary Read-only mailboxes can be deleted => Read-only flag on mailboxes must be respected 19-May-06 23:14 windowsrefund Note Added: 0001184 20-May-06 00:01 windowsrefund Note Edited: 0001184 20-May-06 00:12 aaron Note Added: 0001185 20-May-06 13:58 paul Note Added: 0001188 20-May-06 20:20 aaron Note Added: 0001189 20-May-06 20:21 aaron Relationship added related to 0000347 12-Jun-06 05:49 aaron Note Added: 0001243 12-Jun-06 18:23 aaron Relationship added child of 0000366 03-Sep-06 14:03 paul Note Added: 0001385 04-Sep-06 19:50 aaron Note Added: 0001391 07-Sep-06 20:30 aaron Note Added: 0001396 09-Sep-06 11:05 aaron Status feedback => resolved 09-Sep-06 11:05 aaron Resolution reopened => fixed 09-Sep-06 11:05 aaron Note Added: 0001397 ======================================================================
