Hi Dieter,Gavin and all,
I have mentioned in my last mail that I had ACL like
################ personal ACL ####################### ###################### read ####################### access to dn.regex="cn=([^,]+),ou=personal,ou=contacts,ou=contacts,virtualDomain=([^,]+),dc=suse,dc=ldap$" by dn.exact,expand="uid=$1,ou=users,virtualDomain=$2,dc=suse,dc=ldap" read by * none ######################## write ############################ access to dn.regex="cn=([^,]+),ou=personal,ou=contacts,ou=contacts,virtualDomain=([^,]+),dc=suse,dc=ldap"
attr=children,entry,@inetOrgPerson,@posixAccount,@mozillaAbPersonAlpha,@evolutionPerson by dn.exact,expand="uid=$1,ou=users,virtualDomain=$2,dc=suse,dc=ldap" write by users none
the problem if writing was it reports
Jul 9 11:59:33 lvps87-230-8-228 slapd[5147]: => access_allowed: write access denied by read(=rscx)
So I disabled the read ACL and the problem disappeared. I have a question here that why we need the read ACL at all more over thing is not so easy for Group ACL. If I follow the same technique for group ACL then though the group has no delete option it can delete the entries easily. how can I fix this problem. thanks so far for giving me the helpful suggestions; thans a lot
On Mon, 9 Jul 2007, JOYDEEP wrote:
I have mentioned in my last mail that I had ACL like
################ personal ACL ####################### ###################### read ####################### access to dn.regex="cn=([^,]+),ou=personal,ou=contacts,ou=contacts,virtualDomain=([^,]+),dc=suse,dc=ldap$" by dn.exact,expand="uid=$1,ou=users,virtualDomain=$2,dc=suse,dc=ldap" read by * none
Since that has no control field, it defaults to 'stop', so that checks that match the <what> clauses (just a dn.regex clause, in this case) will stop after processing that access directive. Later directives that might also match will not be processed.
######################## write ############################ access to dn.regex="cn=([^,]+),ou=personal,ou=contacts,ou=contacts,virtualDomain=([^,]+),dc=suse,dc=ldap"
attr=children,entry,@inetOrgPerson,@posixAccount,@mozillaAbPersonAlpha,@evolutionPerson by dn.exact,expand="uid=$1,ou=users,virtualDomain=$2,dc=suse,dc=ldap" write by users none
(That should be "attrs=children,etc..", as "attr=" is undocumented, though tolerated by slapd)
the problem if writing was it reports
Jul 9 11:59:33 lvps87-230-8-228 slapd[5147]: => access_allowed: write access denied by read(=rscx)
So I disabled the read ACL and the problem disappeared.
Right, because the first access directive wasn't letting the processing reach the second access directive.
However, that second directive only gives access to some of the attributes, unlike your first access directive which gives access to all of them. To permit read access to all attributes and write access to only some then you'll need to access directive, at least one of which has a control field of 'break'. Whether they both require that depends on whether later access directives should also be applied to that same DN.
I have a question here that why we need the read ACL at all more over thing is not so easy for Group ACL.
I cannot parse that sentence at all.
If I follow the same technique for group ACL then though the group has no delete option it can delete the entries easily.
"delete option"? There isn't a 'delete' access level. To quote the slapd.access(5) manpage: The delete operation requires write (=w) privileges on the pseudo-attribute entry of the entry being deleted, and write (=w) privileges on the children pseudo-attribute of the entry's parent.
Note that those are the exact same privileges as are needed to add an entry. It appears that you can't give someone permission to add an entry but not delete it.
Philip Guenther
openldap-software@openldap.org