[Dovecot] vfile ACL's
(Sorry for the impatience. This was one of several questions in my email from yesterday. I thought I might have better luck being more direct.)
Is there a way to set ACL's, using the vfile backend, on a truly global basis? or hierarchically (i.e. .Maildir.Sub inherits from .Maildir)?
The wiki page says: "The default ACLs for mailboxes is to give owner all permissions and other users none. Mailboxes in public namespaces don't have owners, so by default no-one can access them."
Is this configurable?
Thanks, Ben
On Fri, 2007-08-03 at 09:34 -0400, Benjamin R. Haskell wrote:
(Sorry for the impatience. This was one of several questions in my email from yesterday. I thought I might have better luck being more direct.)
Is there a way to set ACL's, using the vfile backend, on a truly global basis? or hierarchically (i.e. .Maildir.Sub inherits from .Maildir)?
I thought there was something like that, but looks like not. I don't remember if this is because there was a problem with adding support for them or if I simply haven't gotten around to implementing them yet.
On Sun, 5 Aug 2007, Timo Sirainen wrote:
On Fri, 2007-08-03 at 09:34 -0400, Benjamin R. Haskell wrote:
(Sorry for the impatience. This was one of several questions in my email from yesterday. I thought I might have better luck being more direct.)
Is there a way to set ACL's, using the vfile backend, on a truly global basis? or hierarchically (i.e. .Maildir.Sub inherits from .Maildir)?
I thought there was something like that, but looks like not. I don't remember if this is because there was a problem with adding support for them or if I simply haven't gotten around to implementing them yet.
Thanks for the response.
I worked around the actual problem (in "[Dovecot] Shared folder hierarchies, multiple groups") with the following patch:
http://benizi.com/dovecot-1.0.1-namespace-hack.patch
It's probably not the "correct" thing to do. (Hence "-hack".) But, it did seem to be the minimal set of changes required to accomplish what I wanted (shared folders implemented via namespaces with permissions controlled by the namespace INBOX's group).
It changes the following:
src/imap/cmd-list.c - list_namespace_init In the IMAP LIST command, when checking namespace INBOX'es, if the INBOX folder's path exists and is not readable, it doesn't list it.
src/lib-storage/index/maildir/maildir-list.c - maildir_fill_readdir If it fails to open the directory because permission was denied, it sets an open_flag, but doesn't set_critial, and returns false.
src/lib-storage/index/maildir/maildir-list.c - maildir_mailbox_list_init If maildir_fill_readdir fails, and the HIDEYHACK flag is set, it returns in the same place as a failure would, but doesn't set .failed on the context.
src/lib-storage/index/maildir/maildir-storage.c - verify_inbox Checks permissions on the directory path. If the folder exists, but is unreadable, it returns 0 (= verifies OK), but logs an error to assist in actual-error debugging.
If there's anything *glaringly* wrong with this approach, please let me know.
Best, Ben
participants (2)
-
Benjamin R. Haskell
-
Timo Sirainen