Timo Sirainen wrote:
On 19.5.2005, at 18:15, Chris Wakelin wrote:
I've had a go at adding a "readonly" namespace option to dovecot-1.0-stable. My idea is to provide access to NetApp ".snapshot" versions of NFS-mounted maildirs to let users recover their own messages. I'm not sure whether anyone else would find it useful, but here it is in case :-)
There are two patches, one to add the option, the other to add some checking to various IMAP commands just in case the client doesn't behave itself when told the mailbox is read-only ;-)
How about if the readonly setting was set as parameter in location setting, so the storage code could handle it itself and set itself to read-only state? Dovecot already supports read-only mboxes and maildirs so I think this way you wouldn't have to add extra readonly-checks.
That might be better, but two lots of code to write, I guess! I think there might still need to be checks for the commands, I tried opening a folder with "EXAMINE" rather than "SELECT" and seeing if Dovecot would let me alter flags and it did ...
Although you'd still have to add checks for create/delete/rename commands and that code would be mbox/maildir specific then..
Yes, that's where it gets messy. In my version, I don't like having to have a special function to check the namespace flag, and the checks only work for the case where it's the namespace option that's made the folder readonly, so it's not very general.
But as you said, ACLs would be the real solution :) Hmm. Perhaps it's time to start thinking about those too. Normally ACLs would be set by user itself for his own mailboxes. That case should be pretty simple. We could use some ACL-file and possibly filesystem's own permissions as well. I think for public folders you'd also have them in some namespace, and the ACLs be defined in there in a separate ACL-file.
I think ACLs would be nice, but not as important to me as say, allowing specific folders to be in different filesystems or formats (maybe a little like Cyrus' mailboxes database - ideally I want INBOXes and "Sent Items" folders on our mirrored NetApps for redundancy and the rest on our local RAID5 arrays ...)
With ACLs, how about being able to define a default ACL for each namespace (generalising my "readonly" option) and optionally allow users to override it for their folders? Perhaps the user-specified ACL can be stored in a special header in the folder like X-IMAPbase (or is that asking for trouble?) to save having to open another file for each folder.
But what about the kind of ACL-support your snapshots-case would need? It's kind of a special case because it's a namespace that points to different location for every user. I think this falls into same category as nondeletable folders that some people want for Drafts/Trash/etc. Would we need some globally defined ACL blocks in configuration file where you can give a list of folder masks where it's effective? Maybe..
That might also be a way of generalising the folder location, but I thought that might be quite hard to implement (beyond me anyway!).
Maybe something like :-
namespace private { separator = / prefix = acl = owner:rwcd
folder Trash { acl = owner:rw location = /export/cheap/storage/%u/[] } folder Sent* { location = maildir:/export/mirrored/%u/[] } }
namespace private { prefix = "#snapshot" location = maildir:/export/mirrored/.snapshot/nightly.0/%u acl = owner:r }
namespace public { prefix = "#public" acl = owner:rwcd everyone:r location = maildir:/export/public }
where r/w/c/d is read/write/change acl/delete?
I'm not sure how that would fit in with file permissions though!
Best Wishes, Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094