dovecot - Aug 2007 - 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070805/871d62cb/attachment-0002.bin>

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:

1. 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.

2. 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.

3. 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.

4. 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