Re: commit: ldap/servers/slapd/overlays dyngroup.c

[Russ Allbery <rra@stanford.edu>]

Pierangelo Masarati <ando@sys-net.it> writes:

> I disagree: by running an internal operation with dgIdentity, and
> returning the results of that operation, you'd break the security model
> of OpenLDAP.  In fact, a dynamic group can unveal data that would
> otherwise be inaccessible to a user.

This is *exactly* the behavior that Stanford needs, so please make sure
that this is still possible.

Use case:

    Privileges are represented in the directory via entitlements; in other
    words, a given user has a multivalued attribute in their directory
    record that contains the entitlements that user has.

    Applications need to be allowed to verify, for authorization purposes,
    that a given user has a given entitlement, but which applications can
    see which entitlements needs to vary on an entitlement-by-entitlement
    basis (for example, some entitlements may represent data protected by
    FERPA, the US student information privacy act).

We want to add regular groups to the directory (rather than using compare
tests against the entitlement attribute) because we can put separate ACLs
on each group and then lock down access to the entitlement attribute
entirely.  Otherwise, we end up with a ton of substring ACLs on the
entitlement attribute, which is a performance and maintenance problem.

So, that behavior of letting the dynlist or dyngroup overlay do a query
that the user querying the group tree is not themselves permitted to make
is exactly what we need, since we can then use the more granular access
control possible on the separate group dns to implement control over
entitlement visibility that's otherwise annoying to represent.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>