Hi all,
Is it possible to define an ACL that gives a DN access to a particular attribute in other DNs based on the value of one of its own attributes?
For example, would it be possible to define an ACL that would allow a DN with title=telephonemanager to update only the telephoneNumber attribute of other DNs? In other words, the ACL would allow updates to telephoneNumber, but only for search filter title=telephonemanager; a simple a change of the title would result in the gain or loss of the right to make such updates.
Thanks,
Jaap
Jaap Winius jwinius@umrk.nl writes:
Hi all,
Is it possible to define an ACL that gives a DN access to a particular attribute in other DNs based on the value of one of its own attributes?
For example, would it be possible to define an ACL that would allow a DN with title=telephonemanager to update only the telephoneNumber attribute of other DNs? In other words, the ACL would allow updates to telephoneNumber, but only for search filter title=telephonemanager; a simple a change of the title would result in the gain or loss of the right to make such updates.
man slapd.access(5) http://www.openldap.org/faq/data/cache/429.html http://www.openldap.org/faq/data/cache/1133.html
-Dieter
Quoting Dieter Kluenter dieter@dkluenter.de:
man slapd.access(5)
Yes, I'm interested in the <WHO> field, but it seems none of what's mentioned here can be based on the value of an attribute (e.g. title=telephonemanager).
Specifying <WHAT> is the easy part.
Looks like a description of the "set" option, which is missing from man slapd.access(5). It's quite complex, unfortunately, but I still don't see how the set option would allow me to compare the value of a particular attribute to a predetermined value, and use that as the only measure for determining access. I need something like:
access to attrs=telephoneNumber by "users && attrs=(title=telephonemanager)" write
This is pure nonsense, but it's short and I hope that it better illustrates what I'm looking for. Any ideas?
Thanks,
Jaap
--On Sunday, January 31, 2010 7:12 PM +0100 Jaap Winius jwinius@umrk.nl wrote:
access to attrs=telephoneNumber by "users && attrs=(title=telephonemanager)" writeThis is pure nonsense, but it's short and I hope that it better illustrates what I'm looking for. Any ideas?
From slapd.access(5)
The statement filter=<ldapfilter> selects the entries based on a valid LDAP filter as described in RFC 4515. A filter of (objectClass=*) is implied if no filter form is given.
Take a look at:
http://www.stanford.edu/services/directory/openldap/configuration/slapd-acl.html
There's a clear example of using an attribute value to filter access.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Sunday, January 31, 2010 11:09 AM -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Sunday, January 31, 2010 7:12 PM +0100 Jaap Winius jwinius@umrk.nl wrote:
access to attrs=telephoneNumber by "users && attrs=(title=telephonemanager)" writeThis is pure nonsense, but it's short and I hope that it better illustrates what I'm looking for. Any ideas?
From slapd.access(5)
The statement filter=<ldapfilter> selects the entries based on avalid LDAP filter as described in RFC 4515. A filter of (objectClass=*) is implied if no filter form is given.
Take a look at:
http://www.stanford.edu/services/directory/openldap/configuration/slapd- acl.html
There's a clear example of using an attribute value to filter access.
Blah, I was thinking this in the wrong direction. Sets are likely what you need. I think the syntax would be more
by set.exact="user/title=telephonemanager" write
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quoting Quanah Gibson-Mount quanah@zimbra.com:
Blah, I was thinking this in the wrong direction. Sets are likely what you need. I think the syntax would be more
by set.exact="user/title=telephonemanager" write
This looks great, but I've tested it (with slapd v2.4.11) and unfortunately it doesn't want to work. Could there any special requirements that might be necessary before sets can be used?
Thanks!
Jaap
--On Sunday, January 31, 2010 11:22 PM +0100 Jaap Winius jwinius@umrk.nl wrote:
Quoting Quanah Gibson-Mount quanah@zimbra.com:
Blah, I was thinking this in the wrong direction. Sets are likely what you need. I think the syntax would be more
by set.exact="user/title=telephonemanager" write
This looks great, but I've tested it (with slapd v2.4.11) and unfortunately it doesn't want to work. Could there any special requirements that might be necessary before sets can be used?
Unfortunately sets aren't fully documented, so I can't say.
I would note that I'd personally just create a group for the IT managers, and then do access based off the group...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quoting Quanah Gibson-Mount quanah@zimbra.com:
Unfortunately sets aren't fully documented, so I can't say.
It's been a full decade since Mark Valence introduced us to sets, which is sad, because it is said to be so useful. You know, I wouldn't mind helping out with writing that documentation for the project... as long I would have someone with enough knowledge of the subject to collaborate with.
I would note that I'd personally just create a group for the IT managers, and then do access based off the group...
Sure, but since this is actually a purely theoretical question, that would be missing the point. An old friend of mine from NIU, a directory specialist who works with eDir (and MAD, which he doesn't think much of), inspired me. He doesn't know much about OpenLDAP, but he has seen some things and it was this particular bit of functionality that made a lasting impression on him. He believes it's a technical advantage that OpenLDAP has over the competition. I imagine that it would scratch an itch that he is currently unable to reach.
Anyway, these are my current ACLs in full (using Kerberos for authentication):
access to attrs=userPassword,shadowLastChange by * none
access to dn.base="" by * read
access to attrs=loginShell by self write by * read
access to attrs=telephoneNumber by set.exact="user/title=telephonemanager" write
#access to attrs=telephoneNumber # by dn=uid=tmgr,ou=users,dc=example,dc=com write
access to * by anonymous auth by users read by * none
Using the above ACLs and uid=tmgr, which has "title: telephonemanager", if I attempt to modify the telephoneNumber of another user, I receive the error:
ldap_modify: Insufficient access (50)
However, if I uncomment the second to last access directive and comment out the one above it, then I can make that same modification without any problem.
If you or anyone else has an idea what might be preventing this "set" filter from working, I'd be much obliged.
Thanks,
Jaap
Jaap Winius jwinius@umrk.nl writes:
Quoting Quanah Gibson-Mount quanah@zimbra.com:
Blah, I was thinking this in the wrong direction. Sets are likely what you need. I think the syntax would be more
by set.exact="user/title=telephonemanager" write
This looks great, but I've tested it (with slapd v2.4.11) and unfortunately it doesn't want to work. Could there any special requirements that might be necessary before sets can be used?
this rule should do the trick: access to dn.regex="cn=([^,]+),ou=whatsoever$" attrs=telephoneNumber by set="user/title & [telephoneManager]" write
-Dieter
Quoting Dieter Kluenter dieter@dkluenter.de:
this rule should do the trick: access to dn.regex="cn=([^,]+),ou=whatsoever$" attrs=telephoneNumber by set="user/title & [telephoneManager]" write
Yes!!!
This is what I'm using now:
access to attrs=telephoneNumber by set="user/title & [telephonemanager]" write by users read
This works for a user with attr title=telephonemanager. However, to demonstrate the flexibility of this set rule...
access to attrs=telephoneNumber by set="user/description & [telephonemanager]" write by users read
... this works for a user with attr description=telephonemanager!
This is cool regardless, but I think my NIU-friend would say that it's cool because this set rule allows you to give users telephonemanager privileges without the need to maintain a telephonemanager group.
Actually, I think this solution can be improved upon significantly. For example, what if our privileged user had this attribute:
description: titlemanager telephonemanager addressmanager
Can a a set rule be devised to match not only users with a description value that equals "telephonemanager", but also one that includes it in a longer string? We would need something like:
access to attrs=telephoneNumber by set="user/description & [*telephonemanager*]" write by users read
Only, that doesn't work.
Is this possible?
Many thinks,
Jaap
Jaap Winius jwinius@umrk.nl writes:
Quoting Dieter Kluenter dieter@dkluenter.de:
[...]
This works for a user with attr title=telephonemanager. However, to demonstrate the flexibility of this set rule...
access to attrs=telephoneNumber by set="user/description & [telephonemanager]" write by users read
... this works for a user with attr description=telephonemanager!
This is cool regardless, but I think my NIU-friend would say that it's cool because this set rule allows you to give users telephonemanager privileges without the need to maintain a telephonemanager group.
Actually, I think this solution can be improved upon significantly. For example, what if our privileged user had this attribute:
description: titlemanager telephonemanager addressmanager
This is a single value, you actually want a multi valued attribute type.
Can a a set rule be devised to match not only users with a description value that equals "telephonemanager", but also one that includes it in a longer string? We would need something like:
access to attrs=telephoneNumber by set="user/description & [*telephonemanager*]" write by users read
Only, that doesn't work.
Is this possible?
Did you define an index for description? But still I don't think this could work, although I have never tested this.
-Dieter
Quoting Dieter Kluenter dieter@dkluenter.de:
description: titlemanager telephonemanager addressmanager
This is a single value, you actually want a multi valued attribute type.
Doh!
Did you define an index for description? ...
No, but that sounds like a good idea.
Quoting Howard Chu hyc@symas.com:
It is unnecessary. The description attribute is multivalued, just use it correctly.
Doh!
Okay, then the set rule is obviously fine the way it is.
I'll also note that using a set for this purpose is still inferior to using a dynamic group, in terms of performance. Dynamic group evaluations are cached, sets are not.
If this "set" solution were to be used on a DIT with 100,000 entries, would it really slow things down significantly, assuming the description attribute was indexed?
Thanks,
Jaap
Jaap Winius wrote:
Quoting Dieter Kluenterdieter@dkluenter.de:
this rule should do the trick: access to dn.regex="cn=([^,]+),ou=whatsoever$" attrs=telephoneNumber by set="user/title& [telephoneManager]" write
Yes!!!
This is what I'm using now:
access to attrs=telephoneNumber by set="user/title& [telephonemanager]" write by users readThis works for a user with attr title=telephonemanager. However, to demonstrate the flexibility of this set rule...
access to attrs=telephoneNumber by set="user/description& [telephonemanager]" write by users read... this works for a user with attr description=telephonemanager!
This is cool regardless, but I think my NIU-friend would say that it's cool because this set rule allows you to give users telephonemanager privileges without the need to maintain a telephonemanager group.
Actually, I think this solution can be improved upon significantly. For example, what if our privileged user had this attribute:
description: titlemanager telephonemanager addressmanagerCan a a set rule be devised to match not only users with a description value that equals "telephonemanager", but also one that includes it in a longer string? We would need something like:
access to attrs=telephoneNumber by set="user/description& [*telephonemanager*]" write by users readOnly, that doesn't work.
Is this possible?
It is unnecessary. The description attribute is multivalued, just use it correctly.
description: titlemanager description: telephonemanager description: addressmanager
I'll also note that using a set for this purpose is still inferior to using a dynamic group, in terms of performance. Dynamic group evaluations are cached, sets are not.
openldap-technical@openldap.org
-
Dieter Kluenter -
Howard Chu -
Jaap Winius -
Quanah Gibson-Mount