[dovecot] Re: shared folders?

[Moe Wibble]

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