On 16/03/2011 18:21, Andrew Findlay wrote:
On Wed, Mar 16, 2011 at 05:31:27PM +0200, George Mamalakis wrote:
I am trying to find a way to hide/unhide attributes on my DIT (openldap-2.4.21) and I cannot find a way to do this. What I mean by hide/unhide is that I want specific attributes to be listed with ldapsearch only if the owner of the records agrees. I did not find any feature that does this "automatically", so I tried to implement it through acls. I created a group called i.e. "cn=publish mail,ou=Groups,dc=example,dc=com" where people wishing to disclose their emails are members of this group. On the acl statement I couldn't find a way to restrict my acl based on "conditional attributes".
There are several ways to do that. See my paper on ACL design for some examples:
http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/
Parts of section 10.5 might be useful, but as that is a rather complex example I suggest you do not start there!
Andrew
Andrew,
I haven't read your paper yet, but I will, since it seems very informing! I came up to a "partial solution" in the meantime that reads like this:
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
with this acl I manage to filter out anonymous users, allow self to change/add their mail and show everybody else the entry's mail, if the dn belongs to the specific group. Since anonymous is out, the rest of the users must be authenticated, and hence I 'converge' to my wished 'by users read'. It is not mathematically *exactly* what I wished for (I think...since I am not sure what other sort of users would exist, but the truth is that other dn's would be able -somehow- to access this tree...), but it is very, very, very close to it.
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?
Thanx again for your immediate answer and help,
mamalos