On Mar 17, 2009, at 12:08 PM, Timo Sirainen wrote:
On Mar 16, 2009, at 4:12 PM, Timo Sirainen wrote:
Hmm. I'm not sure if there's a reason for the existence of the
default
ACLs being looked up from dovecot-acl file. I think the initial fix
could be to simply not do that. If someone really wa
On Mar 16, 2009, at 4:12 PM, Timo Sirainen wrote:
Hmm. I'm not sure if there's a reason for the existence of the default
ACLs being looked up from dovecot-acl file. I think the initial fix
could be to simply not do that. If someone really wants to have
different default ACLs they could perhaps b
On 16.03.2009, Timo Sirainen wrote:
> On Mon, 2009-03-16 at 20:33 +0100, Bernhard Herzog wrote:
> > That pathological aclobj is created in acl_backend_init:
> > backend->default_aclobj = acl_object_init_from_name(backend, NULL, "").
> > acl_object_init_from_name calls acl_backend_vfile_object_ini
On Mon, 2009-03-16 at 20:33 +0100, Bernhard Herzog wrote:
> That pathological aclobj is created in acl_backend_init:
> backend->default_aclobj = acl_object_init_from_name(backend, NULL, "").
> acl_object_init_from_name calls acl_backend_vfile_object_init, which sets the
> aclobj's local_path.
On 13.03.2009, Bernhard Herzog wrote:
> On 10.03.2009, Timo Sirainen wrote:
> > I've been a bit busy (or lazy) recently and I'm not focusing on trying
> > to get the new dbox code working. I'll look at the ACL bugs at some
> > point, but you can probably get them fixed sooner if you do it yourself.
On 10.03.2009, Timo Sirainen wrote:
> I've been a bit busy (or lazy) recently and I'm not focusing on trying
> to get the new dbox code working. I'll look at the ACL bugs at some
> point, but you can probably get them fixed sooner if you do it yourself.
I'm going to look into this.
Bernhard
-
On Mon, 2009-03-09 at 16:46 +0100, Sascha Wilde wrote:
> > That shouldn't happen. There's no code for doing recursive ACLs. Sounds
> > more like a bug somewhere. I'll check it later.
>
> Hi, have you already found the time to have a look at it? Otherwise it
> might be a good idea if we (== any of
Timo Sirainen writes:
> On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
>> Hi *,
>>
>> The problem is most noticeable when a user shares his INBOX[0][1] with
>> others:
>>
>> User A sets his INBOX acls to "eilprwtsd"
>>
>> Now User B can see _all_ sub mailboxes and sub sub [...] mailboxe
Sascha Wilde writes:
> Timo Sirainen writes:
>> On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
>>> * LIST (\HasChildren) "/" "user/1...@aztec.intevation.de/foobar"
>>
>> [...] Is the mailbox also selectable?
Oh, missed to answer that question: yes, it is selectable and the
contents i
Timo Sirainen writes:
> On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
>> Hi *,
>>
>> The problem is most noticeable when a user shares his INBOX[0][1] with
>> others:
>>
>> User A sets his INBOX acls to "eilprwtsd"
>>
>> Now User B can see _all_ sub mailboxes and sub sub [...] mailbox
On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
> Hi *,
>
> The problem is most noticeable when a user shares his INBOX[0][1] with
> others:
>
> User A sets his INBOX acls to "eilprwtsd"
>
> Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and
> their contents of User A:
Sascha Wilde writes:
Ooops some search and replace missing, the example should read:
> User A:
> g getacl INBOX
> * ACL "INBOX" "a...@example.com" akxeilprwtscd "b...@example.com" eilprwtsd
> "a...@example.com" lrwstipekxacd
> g OK Getacl completed.
> g getacl INBOX/foobar
> * ACL "IN
Hi *,
The problem is most noticeable when a user shares his INBOX[0][1] with
others:
User A sets his INBOX acls to "eilprwtsd"
Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and
their contents of User A:
User A:
g getacl INBOX
* ACL "INBOX" "a...@example.com" akxeilprwts
13 matches
Mail list logo
