Timo Sirainen wrote:
On 25.10.2006, at 16.31, Steffen Kaiser wrote:
I think the "public folders" configuration will stay as it is now. Does it really even need anything else? The problematic case is how the users can share their mailboxes to other users. There are two problems related to it:
- How to get (quickly) a list of another user's mailboxes that I have access to?
You need this information for "LIST"? Just asking, it would help for large folder structures only, right? Otherwise, it adds yet another redundant stuff, one needs to maintain and probably fix, e.g. run a nightly job to verify the symlinks.
Well, I don't think the symlinks would normally break by themselves? Unless you for some reason manually go and delete them, the only problem is if a shared maildir is renamed outside Dovecot.
Mailbox listing is anyway done a lot by the clients, so this operation needs to be pretty fast. Doing a stat(box/dovecot-acls) for each mailbox could get slow if there are a lot of mailboxes.
- How to get quickly a list of all users who have mailboxes that I have access to?
Why do you need this information? Wouldn't it better to pass this information araund via, say, EMail? Then an user may SELECT a specific mailbox directly or can LIST an specific user.
And how do you select a specific mailbox or list a specific user directly with any commonly used IMAP client? You don't, so you'll have to show the list of users who have shared mailboxes to you.
What worries me more is the information in the following two pages: http://wiki.dovecot.org/ACL http://wiki.dovecot.org/SharedFolders
For virtual users (with just one account for all users) there is no problem, but for real users ACLs superceed filesystem permissions. Dovecot would need to maintain the "dovecot-shared" files as well as mangle the permissions correctly.
Yea, this should be implemented some day as some filesystem-backend.
ACLs in the filesystem is support by most platforms and filesystems now (atleast those that I use), does dovecot use this in any way, or rather would a future ACL backend do this?
When an user shares a mailbox to other users, either all these users must belong to one group or Dovecot need to create a group dynamically for them.
Well, I suppose dynamic groups could work, but then you'd have to reserve one GID for each different ACL. Probably too much trouble to implement..
How many people anyway even need to support users who have shell access and can share mailboxes to each others? I don't think all that many.
I do :) I don't have a really urgent need for shared folders between users right now, and symlinks + correct ACL seems to work fine for my use (for now), but it would be a really nice feature.
I think there are just two practical ways to implement this:
Let sysadmin define all the groups and people who are in them. Allow the filesystem ACL backend to manipulate the file mode and group directly.
Use one or more groups for shared mailboxes which gives a group of people access to the mailbox, but the vfile ACL backend is still doing the exact permission checks. Like there could be just one "shared-mails" group which is set for all mailboxes that are shared, but each of then then could contain dovecot-acls file which describes who it's shared to.
Or support actual filesystem ACLs?
What would be nice, (for me :P), is to be able to have groups of users being able to see each others shared folders, say, I have a group "project1" and a group "project2", users in project1 would be able to see all the shared folders of the other users in that group, but not for anyone in the other group "project2" ..
So if I understand it correctly, if we say that only dovecot is making/changing/deleting shared folders, it would be possible to have a back end that stores what folders are shared and such for listing.. and for people to implement "special features" of what shared folders are listed (like my wanted feature above) as a plugin?
Come to think of it, when describing what folders is shared you also say who has access right? (okay, I should read the specs instead of guessing) So if a user gets access to a folder, that folder should be visible to that user? hm, makes my idea a bit redundant, but still :)
Greetings, Asbjorn Sannes