On Fri, Apr 25, 2003 at 08:21:35PM +0300, Timo Sirainen wrote:
On Fri, 2003-04-25 at 20:06, Moe Wibble wrote:
Well, I can't now think of why it wouldn't work :) At least as read-write, read-only wouldn't work now.
Ah yes, I think that was the point where it failed when I tried. Very unfornationate because ro-access for some users to shared folders where others can write is a must for us.
There's mostly just one problem with this. Mails in new/ couldn't be accessed since they couldn't be moved to cur/ and their UID couldn't be saved into uidlist file.
This is actually somewhat related to quota full situation when there's no space to rewrite uidlist file.. Solution should be the same for both, but I'm not sure yet what it is :)
I'd have some ideas for this but I'm not familar with the dovecot code so they might not be applicable.
I'm really looking forward to "completed" sf-support in dovecot.
Courier-like shared maildir folders would probably be best way to do it. It'd use symlinks to message files, so flags can still be changed separately because it's only the user's symlink that gets renamed.
I wrote some kind of plan for shared folder + ACL support a few months ago when there was a possibility of getting paid to do it: (anyone still want to? :)
Uh oh.
- Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling.
Huh?
- Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
What for?
- Support for multiple namespaces
- struct mail_storage == one namespace
- fix all IMAP commands handling mailbox names to support other mail_storages based on the mailbox name prefix
Ugh.
- mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
Why!?
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
Why why why!?
- getgroups() plugin- (Courier compatibility? It used some extra files)
Why not treat shared folders like any other folders? Why the heck do you want to be "compatible" to inconveniences of other software? Wouldn't a one-shot-convert-courier-mailstore-to-dovecot-mailstore- utility be more reasonable than bloating the code with compatiblity- workarounds? Who in the world would want to run dovecot and courier in parallel?
- Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
Ummm. per-mail symlinks? Okay, there are a number of reasons why people want to get rid of courier imap. I'm convinced that would be one of them! Why not store per-user mailflags for a shared folder (shared folder = a folder that is a symlink not directory) in a separate (single?) meta-file? So dovecot sees: "oh a symlink. well, we'd better read the flags from our meta file then, rather than parse the name".
- ACL API design
- Needs to support stackable implementations, so that eg. filesystem ACL is at the bottom, on top of that an .aclrights file for more fine grained non-OS forced ACLs.
- compatible with ACL2 (currently draft), just a few issues
Okay, you're kidding. You are. Aren't you? You are. (*hides under desk*)
- Filesystem ACL implementation for the ACL API
Argh.
- ACL IMAP commands
Mercy!!
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
- In general Dovecot doesn't currently like having read-only access to mailboxes
I noticed that.
- Ask ACL if operation is permitted before doing that, so it can force the soft checks (.aclaccess file etc)
Okay, you got me really scared by now.
I mean... I don't even know where to start... Maybe: What kind of expired fish did you have for breakfast? (j/k;))
The positive point was that you said you're not going to actually do it. Can you promise that, please? ;)
Would you probably take a simpler approach like the one I briefly outlined in my previous mail into consideration or do you really think of ACLs as a must-have? If so, why?
PS: no personal offense intended!
greetinx
MW