[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: read ACL working but write ACL not-[write access denied by read(=rscx)]

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