[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "hidden" attributes in openldap?

On Wed, Mar 16, 2011 at 07:37:23PM +0200, George Mamalakis wrote:

> access to dn.subtree="ou=People,dc=example,dc=com" attrs=mail
>         by anonymous none
>         by self write
>         by set="this & [cn=Publish Mail,ou=Groups,dc=example,dc=com]/uniqueMember " read
>         by * none

> Now to your paper, do you propose a solution/example that does
> exactly what I wish? If so, is it located in section 10.5 explicitly
> or implicitly?

Not exactly what you want, but the example in 10.5
might provide a useful framework. It works by defining
sets of attributes, then selectively granting access
to entries based on the setting of a visibility
attribute in the entry, then selectively granting
access to attribute sets based on who is asking.

You want to allow individual entries to select the
visibility of mail attributes. The group and set
scheme that you propose is one way to do that (though
I would use member rather than uniqueMember). Another
might be to use a visibility attribute in the entry
and a series of rules of the form:

access to filter="(&(objectclass=person)(visibility=mail-users))"
	by users read
	by * break

That rule would be one of a series, ending up with a
default-deny, perhaps something like this:

access to filter="(objectclass=person)"
	by * none

You would need to handle 'self' access in an earlier

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