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