I would like to allow users to ldapmodify a few of their attibutes ...
sshPublicKey,gecos ..

This does not appear to do the trick:

0-14:08 djh@ldap0 ~$
*sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \> cn=config
'(olcDatabase={1}hdb)' olcAccess*
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymou
 s auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
olcAccess: {3}to attrs=sshPublicKey,gecos by self write

Why? I would guess the {2} rule "to * by * read" has precedence.

As I understand it, if I wanted to re-order those rules, I would delete and
rewrite the rules. This would require me to delete the rule that gives
admin the access to write the rules in the first place ... sounds like a
way to lock myself out of my LDAP database?

So, my guess is that I want and LDIF like so:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
remove: olcAccess
olcAccess: {3}to attrs=sshPublicKey,gecos by self write
-
add: olcAccess
olcAccess: {2}to attrs=sshPublicKey,gecos by self write
-
add: olcAccess
olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write by * read
-
remove: olcAccess
olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read

If I run this as cn=admin then it should:

1) Remove ineffective {3}
2) Add an effective {2} (now there are two {2}s..)
3) Add a new {3} to match incumbent {2}
4) Remove incumbent {2}

I shouldn't lock myself out because I add a new rule for admin access
before deleting the old rule, and as far as LDAP is superficially
concerned, all these olcAccess attributes are just unique records, so the
conflicting number rules aren't going to be a problem .. ?

Am I on the right track?

Thanks,
-danny

-- 
http://dannyman.toldme.com

Reply via email to