[Kolab-devel] Redundant LDAP access rules and subsequent crash

[Gunnar Wrobel]

Quoting "Mailingliste TBits.net GmbH" <mailinglists at tbits.net>:

> After running into a Heisenbug in our development tree, it quickly
> turned out that problems arise from the way we generate LDAP ACL
> rules. Upon checking with Martin, I was told that there is an inherent
> flaw in the "Access to domain groups" stanza of slapd.access: When
> adding domains, such will yield something like this:
>
> access to dn.children="cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
>      by
> group/kolabGroupOfNames="cn=admin,cn=internal,dc=intra,dc=tbits,dc=net"
> write
>      by
> group/kolabGroupOfNames="cn=maintainer,cn=internal,dc=intra,dc=tbits,dc=net"
> write
>      by dn="cn=nobody,cn=internal,dc=intra,dc=tbits,dc=net" read
>      by
> group/kolabGroupOfNames="cn=foo.com,cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>      by
> group/kolabGroupOfNames="cn=bar.com,cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>      by
> group/kolabGroupOfNames="cn=baz.com,cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>      by * search stop
>
> Consequently, kolabconf will add one 'by' clause for each domain
> added. When having a large number of domains, I am told the access
> rule will quickly become "too complex" and cause slapd to crash at
> startup.
>
> Now my question is: Is this actually necessary? I consider the
> following (correct me if I'm wrong):
>
> * The cn=foo.com etc. groups contain exactly the domain maintainers
> managing them.
> * The cn=domain-maintainer group contains all domain maintainers.
> * For each domain, everyone in the corresponding cn=foo.com group will
> be granted access to cn=domains.
> * There are no 'empty' domain maintainers (i.e. ones without domains
> to manage).
>
> If this holds true, basic set theory quickly shows that we effectively
> grant access to all domain maintainers, as the union of all cn=foo.com
> *must* be cn=domain-maintainer. Bearing this in mind, wouldn't it be
> much easier to just do what the other user groups do and replace the
> lines
>
>      by
> group/kolabGroupOfNames="cn=foo.com,cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>      by
> group/kolabGroupOfNames="cn=bar.com,cn=domains,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>      ...
>
> with a simple
>
>      by
> group/kolabGroupOfNames="cn=domain-maintainer,cn=internal,dc=intra,dc=tbits,dc=net"
> read
>
> ? This way, the rules wouldn't get too extensive and slapd wouldn't crash.

If it works it sounds like a good suggestion. It is a know problem  
(https://issues.kolab.org/issue2498) and there is also another  
suggestion on how to solve it. I think it just needs some further  
feedback. Can you try to integrate your suggestions into that issue?  
It would be really good to solve this.

Cheers,

Gunnar

>
> Sincerely,
> Simon Bausch,
> TBits.net GmbH
>
>
> ----------------------------------------------------------------
> Diese Nachricht wurde versandt mit Webmail von www.tbits.net.
> This message was sent using webmail of www.tbits.net.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100603/37222c65/attachment.sig>