Re: syncrepl 'access to' constraints

[Maurizio Lo Bosco <maurizio.lobosco@eng.it>]

> Maurizio Lo Bosco wrote:
> > I don't know why but without the read access granted to the Radius User
> > the replace modify is not propagated to the consumers.
> > What am I missing?
>
> Sounds like you've encountered ITS#5548, fixed in 2.4.11. Hard to tell
> since that only affects refreshAndPersist and you haven't told us any
> details of your syncrepl configuration.
I apologise for the incomplete informations.

It is exactly the refreshAndPersist syncrepl


Configuration resume:

Debian Etch stable
Openldap 2.3.30-5 on provider and consumer

Consumer syncrepl config in slapd.conf:
syncrepl rid=123
                provider=ldap://192.168.10.4:389
                type=refreshAndPersist
                interval=00:00:02:00
                retry="10 40 60 +"
                searchbase="o=engineering,c=it"
                filter="(objectClass=*)"
                scope=sub
                schemachecking=off
                bindmethod=simple
                binddn="cn=syncuser,ou=sysaccount,o=engineering,c=it"
                credentials=*****

Provider slapd.conf
----------

[...]
sizelimit unlimited
backend         bdb
checkpoint 512 30

database    bdb

suffix      "o=Engineering,c=IT"
rootdn      "cn=root,o=Engineering,c=IT"
rootpw      ********
directory   /var/lib/openldap/engineering
cachesize   300000

index cn,sn,mail,o,ou pres,eq,sub,subinitial
index uid,member,uidNumber,gidNumber,segretaria pres,eq
index codicefiscale,statusLdap,statoscadenze,applicazione pres,eq
index objectclass,entryCSN,entryUUID pres,eq

moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

access to attrs="userpassword"
        by self write
        by anonymous auth
	by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write
	by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read
access to dn.base="o=Engineering,c=IT"
	by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write
	by users   read
access to attrs=RASPassword
	by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write
	by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" write
	by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read
access to dn.subtree="ou=Persone,o=Engineering,c=IT"
	by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write
	by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read
	by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" read
access to *
	by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write
	by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read
-----------

The Radius User is only used to write the value of the attribute RASPassword 
and nothing else, the replication is made with syncuser credentials.

Concerning the bug I think you have got the point!
-------------
ITS#5548
Access control rules that uses connection data are evaluated using the wrong
connection structure. The problem is in syncprov_matchop() where it around 
line 1233 assigns:

 op2.o_hdr = op->o_hdr;

This causes ACL rules to be tested against the connection that made the 
change, not the syncrepl connection.  It should retain the value from 
ss->s_op.
------------
in this way when I retrieve data with syncuser credentials, the ACL used to 
grant the access is the Radius User's ACL which means just
read the base dn 
write the RASPassword

I have no rights to read other entries.

Unfortunately the debian testing is still freezed on the 2.4.10-3.
I will bypass the problems using a less restricted ACL for the Radius User.
I think the problem can be considered resolved, or at least understood.
Thanks again,
kind regards
  Mau