Re: group ACL Problems, disallow deletion of an object

[Pierangelo Masarati <ando@sys-net.it>]

Oliver Heinz wrote:

> With openldap 2.1.30 (debin sarge) if I use ACLs that restrict access 
> to certain groups if those groups do not exist when accessing the 
> (protected) objects slapd crashes and corrupts the database.
>
> *example*
> access to dn=".*,dc=test,dc=org"
>        attribute=gosaMailForwardingAddress
>        by 
> group/groupOfMailEnhancedUniqueNames/uniqueMember="cn=admin.mailforward,ou=groups,dc=test,dc=org" 
> write
>        by * read
>
> slapd: 
> /home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/servers/slapd/result.c:455: 
> slap_send_ldap_result: Assertion `!(((0x51) <= ((err))) && (((err)) <= 
> (0x61)))&& ( err >= 0 )' failed
>
>
> As a workaround I would like to protect those groups from being 
> deleted/moved to ensure that they exist and the database does not 
> crash. But (write) access to their attributes still has to work. How 
> do I allow to modify attributes but not to delete the whole object?


According to slapd.access(5), to delete an object one needs write 
permissions on the pseudo-attribute "entry" of the object itself and on 
the pseudo-attribute "children" of the object's parent, while to modify 
(i.e. add/replace/delete) the object's attributes one needs write 
permissions on each attribute.  So you could easily design ACLs that 
allow attribute modification but no object deletion:

# implicit, only mentioned in case you want to give someone this right
access to dn.exact="ou=groups,dc=test,dc=org" attrs=children
   by * none

# needed to be able to return results
access to dn.onelevel="ou=groups,dc=test,dc=org" attrs=entry
   by * read

# those who can write attrs
access to dn.onelevel="ou=groups,dc=test,dc=org"
   by <writers> write
   by * read

however this would inhibit object creation as well.  And the rootdn 
would have write permissions anyway.

I don't see any other possibility at the moment.

> 2 ACLs, one with each possible attribute in the attribute line and the 
> rule that allows to write followed by one without an attribute line 
> with read permissions?
>
>
> BTW: is anybody aware of a patch/fix for the upper problem (which 
> would obviously make my workaround obsolete)?

2.1 is not going to be fixed any more, unless any volunteer comes out 
with a fix that can be hosted in the ITS. I'm curious if by any chance 
the problem still occurs in 2.2; can you check? and, in case, would you 
mind filing an ITS?

p.




   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497