On Fri, Feb 01, 2013 at 04:56:18PM +0000, Philip Colmer wrote:

> I have a followup requirement where I need to be able to restrict read access
> to the groups as well as write access. I only want the owners of an object to
> be able to read and write that object. 
>
> The reason for wanting to do this is to ensure that a user only sees the groups
> that they can edit when they are using LDAP Account Manager. We have quite a
> large number of groups and I am trying to head off users complaining that they
> can't find the group they need to edit.
>
> I've been experimenting with the ACLs to try to get it to work but I can only
> get it to work if the owner is explicitly mentioned, rather than indirectly
> mentioned as per the "member of a group" approach.
>
> The ACLs so far are:
>
> access to dn.one="dc=example,dc=com"
>     by users read
>     by * none

If your users are also stored in a subtree of dc=example,dc=com
then you may need to give anonymous users a bit more access to
this node. It depends on how your login process works, in
particular the stage that maps from a username to a DN.

> access to dn.one="ou=groups,dc=example,dc=com"
>     by users read
>     by * none

OK so far.

> access to dn.sub="ou=groups,dc=example,dc=com"
>     attrs=objectClass,uniqueMember
>     by users read
>     by * none

I assume this is to support point (3) below - probably not needed.

> access to dn.sub="ou=groups,dc=example,dc=com"
>     by dnattr="owner" write
>     by users none
>     by * none
>
> access to dn.sub="ou=groups,dc=example,dc=com"
>     by set="this/owner/uniqueMember & user" write
>     by users none
>     by * none

Here you have a problem, as the second clause will never be used.

If you want to allow both direct owners and ownership via
groups then you should merge these two - something like this:

access to dn.sub="ou=groups,dc=example,dc=com"
    by dnattr="owner" write

    by set="this/owner/uniqueMember & user" write

    by * none

I am always a bit wary of putting both direct and indirect
references in the same attribute, just in case some entry that
you think is a user ends up with a uniqueMember attribute
somehow.

> (I know that having 'by users none' is redundant but it is there to be
> explicit)

OK - and you can add it to the merged version if you like.

> The purpose of the ACLs is
>
> 1. Allow everyone to see the OU structure in the domain.
> 2. Allow everyone to see the OUs within the groups OU.

It may not do that. Do you want everyone to see all the OUs, or
only those that they are 'owner' of?
Is there a layer of OUs under ou=groups,dc=example,dc=com with
the actual groups further down? If so, you may need to add a
clause to give access to the intermediate OUs.

> 3. The intention here is to grant enough access to the attributes of a group so
> that slapd can then evaluate the uniqueMember attribute. It isn't entirely
> clear to me whether slapd needs a rule like this or should be able to evaluate
> membership etc before it applies acls for the user.

Slapd will read whatever it needs for internal use in
evaluating ACLs so don't worry about it here.
On the other hand, you *do* need to grant adequate (auth)
access to *user* entries so that anon can authenticate.

> 4. Allow directly mentioned owners to write, nothing to everyone else.
> 5. Allow indirectly mentioned owners to write, nothing to everyone else.

With the change given above, that bit should work.

Andrew
--
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------