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
I had to do it this way:
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read - 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
You can not have, for example, multiple {2} so you have to delete and then add. In this case, I was using sudo to do the ldapmodify instead of admin, so no risk of lockout. What I am wondering is if this is at all like an atomic transaction: either you can apply the whole LDIF at once or not ... if it happens in one go you won't get locked out ...
In the mailing list archives I found a suggestion (no example) that you could somehow insert a rule by number ...
On Mon, Mar 21, 2016 at 2:28 PM, Daniel Howard dannyman@toldme.com wrote:
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:
- Remove ineffective {3}
- Add an effective {2} (now there are two {2}s..)
- Add a new {3} to match incumbent {2}
- 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
Daniel Howard wrote:
I had to do it this way:
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {2}to * by dn="cn=admin,dc=example,dc=com" write by * read
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
You can not have, for example, multiple {2} so you have to delete and then add. In this case, I was using sudo to do the ldapmodify instead of admin, so no risk of lockout. What I am wondering is if this is at all like an atomic transaction: either you can apply the whole LDIF at once or not ... if it happens in one go you won't get locked out ...
In the mailing list archives I found a suggestion (no example) that you could somehow insert a rule by number ...
Read this http://www.openldap.org/lists/openldap-technical/201603/msg00057.html
The LDAP spec already says that LDAPModify is atomic. Read the specs.
openldap-technical@openldap.org