Hi All,
I was wondering how i go about giving LESS access than the default ACL rule.
Lets assume some default permissions set from the FAQ-o-matic :
access to attr=userpassword by self =xw by anonymous auth
access to * by self write by users read
This allows the "standard user" to read all attributes, and write thier own details.
Assuming we add to the above a user that has LESS access than the default ie:
access to attr=c,o,ou,cn,sn,givenName,mail by dn.exact=cn=limited,dc=example,dc=com by * none (or break)
This literally wont work as intended, because even if the above does not match, the
access to * by self write by users read
Will always give users read by default.
Any ideas ?
Cheers Brett
On Tue, 2 Dec 2008, Brett @Google wrote:
Hi All,
I was wondering how i go about giving LESS access than the default ACL rule.
Lets assume some default permissions set from the FAQ-o-matic :
access to attr=userpassword by self =xw by anonymous auth
access to * by self write by users read
This allows the "standard user" to read all attributes, and write thier own details.
Does it? I think it'll stop reads on userPassword, actually.
Assuming we add to the above a user that has LESS access than the default ie:
1> access to attr=c,o,ou,cn,sn,givenName,mail 2> by dn.exact=cn=limited,dc=example,dc=com 3> by * none (or break)
This literally wont work as intended, because even if the above does not match, the
7> access to * 8> by self write 9> by users read
Will always give users read by default.
For one thing, don't you want a directive on the line I marked as #2?
Let's assume that you add "read". That point isn't limiting them from reading "mail" nor "givenName", the point is that you want to stop them from reading userPassword or secretAgentID or whatever.
So you need the best matching for "access to <whatever> attr=userPassword," which of course would be the clause starting with the line I marked as #7. You need a more explicit rule to stop them. So perhaps you'd add something along the lines of:
4 access to * attr=userPassword,secretAgentID 5 by dn.exact="cn=limited,dc=example,dc=com" none 6 by * break
Alternately, perhaps you want to make line 1 an affirmative list. In that case, just add #5 as #7.5, ignoring #4-6.
On Tue, Dec 02, 2008 at 02:14:52PM +1000, Brett @Google wrote:
Assuming we add to the above a user that has LESS access than the default ie:
access to attr=c,o,ou,cn,sn,givenName,mail by dn.exact=cn=limited,dc=example,dc=com by * none (or break)
This literally wont work as intended, because even if the above does not match, the
access to * by self write by users read
Will always give users read by default.
You could split the rule into two clauses:
access to attr=c,o,ou,cn,sn,givenName,mail,entry by dn.exact=cn=limited,dc=example,dc=com read by * break
access to * by dn.exact=cn=limited,dc=example,dc=com none by * break
Note that I have added the 'entry' pseudo-atribute to the first clause. Depending on the structure of your DIT you may also need to add rules to permit access to the RDN components of entries higher up the tree.
The 'by * break' statement is an easy way of making sure this clause does not affect any other users.
Andrew
On Wed, Dec 3, 2008 at 12:30 AM, Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
You could split the rule into two clauses:
access to attr=c,o,ou,cn,sn,givenName,mail,entry by dn.exact=cn=limited,dc=example,dc=com read by * break
access to * by dn.exact=cn=limited,dc=example,dc=com none by * break
Thanks for your assistance andrew, this approach seems to be working well.
I needed to add more attributes, but primarily only to make my ldap browser happy, allow syncrepl, and some handy informational attributes for the carbon based lifeforms who maintain the data.
Cheers Brett
For posterity, and google, the final config came out as:
# allow replicator to read all access to * by dn.exact="cn=replicator,dc=example,dc=com" read by * break
# restrcted set of non-operational attributes access to attr=c,o,ou,cn,sn,givenName,mail,entry by dn.exact="cn=limited,dc=example,dc=com" read by * break
# for browsing / syncrepl access to attr=objectClass,hasSubordinates,entryDN,entryCSN,entryUUID by dn.exact="cn=limited,dc=example,dc=com" read by * break
# modify/create information access to attr=createTimeStamp,modifyTimestamp,creatorsName,modifiersName by dn.exact="cn=limited,dc=example,dc=com" read by * break
# disallow other access by limited user access to * by dn.exact="cn=limited,dc=example,dc=com" none by * break
# default rules access to * by self write by * read
access to * by dn.exact="cn=replicator,dc=example,dc=com" read by * break
Remember time and size limits.
On Thu, Dec 04, 2008 at 12:57:13PM +1000, Brett @Google wrote:
I needed to add more attributes, but primarily only to make my ldap browser happy, allow syncrepl, and some handy informational attributes for the carbon based lifeforms who maintain the data.
# allow replicator to read all access to * by dn.exact="cn=replicator,dc=example,dc=com" read by * break
That should be enough for syncreply (assuming you remove the time and size limits as Gavin pointed out). No rules below this will apply to the replicator user.
# restrcted set of non-operational attributes access to attr=c,o,ou,cn,sn,givenName,mail,entry by dn.exact="cn=limited,dc=example,dc=com" read by * break
# for browsing / syncrepl access to attr=objectClass,hasSubordinates,entryDN,entryCSN,entryUUID by dn.exact="cn=limited,dc=example,dc=com" read by * break
objectclass would certainly be needed by most LDAP browsers. The others may not be relevant unless you are running a replica whose content is defined by the ACLs that apply to "cn=limited,dc=example,dc=com"
Andrew
openldap-software@openldap.org
-
Aaron Richton -
Andrew Findlay -
Brett ＠Google -
Gavin Henry