SyncRepl - no write access

[Turbo Fredriksson <turbo@bayour.com>]

Quoting Turbo Fredriksson <turbo@bayour.com>:

I've started (again, I've lost the previous attempts
I did a couple of months ago) to play with SyncRepl
again...

But I can't seem to be able to do the synchronisation.

Running the consumer slapd with '-d -1' I get:

----- s n i p -----
=> access_allowed: search access to "o=Bortheiry,c=SE" "entryUUID" requested
=> dn: [2] cn=ldapsync,c=se
=> dn: [3] cn=syncrepl1,c=se
=> dn: [4] 
=> dn: [5] 
=> dn: [6] cn=monitor
=> dn: [7] cn=subschema
=> acl_get: [8] attr entryUUID
=> acl_mask: access to entry "o=Bortheiry,c=SE", attr "entryUUID" requested
=> acl_mask: to value by "uid=replica,ou=system,o=domain.tld,c=se", (=n)
<= check a_dn_pat: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
<= check a_dn_pat: uid=replica,ou=system,o=domain.tld,c=se
<= acl_mask: [2] applying write(=wrscx) (stop)
<= acl_mask: [2] mask: write(=wrscx)
=> access_allowed: search access granted by write(=wrscx)
<= test_filter 6
send_ldap_result: conn=4294967295 op=0 p=0
send_ldap_result: err=0 matched="" text=""
bdb_modify: o=Bortheiry,c=SE
bdb_dn2entry("o=bortheiry,c=se")
bdb_modify_internal: 0x000000da: o=Bortheiry,c=SE
=> access_allowed: write access to "o=Bortheiry,c=SE" "o" requested
=> dn: [2] cn=ldapsync,c=se
=> dn: [3] cn=syncrepl1,c=se
=> dn: [4]
=> dn: [5]
=> dn: [6] cn=monitor
=> dn: [7] cn=subschema
=> acl_get: [8] attr o
=> acl_mask: access to entry "o=Bortheiry,c=SE", attr "o" requested
=> acl_mask: to all values by "", (=n)
<= check a_dn_pat: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
<= check a_dn_pat: uid=replica,ou=system,o=domain.tld,c=se
<= check a_dn_pat: uid=syncuser,ou=system,o=domain.tld,c=se
<= aci_mask grant =rsc deny =n
<= acl_mask: [3] applying +rsc (stop)
<= acl_mask: [3] mask: =rsc
=> access_allowed: write access denied by =rsc
bdb_modify: modify failed (50)
----- s n i p -----

It's obviosly (?) bound as 'uid=replica,ou=system,o=domain.tld,c=se',
but why does it try to write with an empty DN?!

----- s n i p -----
syncrepl [...]
         updatedn="uid=replica,ou=System,o=Domain.Tld,c=SE"
         bindmethod=simple
         binddn="uid=syncuser,ou=System,o=Domain.Tld,c=SE"
         credentials=secret_in_cleartext
----- s n i p -----

I've also tried sasl/gssapi instead of simple:

----- s n i p -----
syncrepl [...]
         updatedn="uid=replicator,cn=domain.tld,cn=gssapi,cn=auth"
         bindmethod=sasl
         binddn="uid=replicator,cn=domain.tld,cn=gssapi,cn=auth"
         saslmech=GSSAPI
         realm=DOMAIN.TLD
         authcId=replicator
----- s n i p -----

This results in (almost) the exact same output - anonymous write:

----- s n i p -----
=> access_allowed: search access to "o=Bortheiry,c=SE" "entryUUID" requested
=> dn: [2] cn=ldapsync,c=se
=> dn: [3] cn=syncrepl1,c=se
=> dn: [4] 
=> dn: [5] 
=> dn: [6] cn=monitor
=> dn: [7] cn=subschema
=> acl_get: [8] attr entryUUID
=> acl_mask: access to entry "o=Bortheiry,c=SE", attr "entryUUID" requested
=> acl_mask: to value by "uid=replicator,cn=domain.tld,cn=gssapi,cn=auth", (=n) 
<= check a_dn_pat: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
<= acl_mask: [1] applying write(=wrscx) (stop)
<= acl_mask: [1] mask: write(=wrscx)
=> access_allowed: search access granted by write(=wrscx)
<= test_filter 6
send_ldap_result: conn=4294967295 op=0 p=0
send_ldap_result: err=0 matched="" text=""
bdb_modify: o=Bortheiry,c=SE
bdb_dn2entry("o=bortheiry,c=se")
bdb_modify_internal: 0x000000da: o=Bortheiry,c=SE
=> access_allowed: write access to "o=Bortheiry,c=SE" "o" requested
=> dn: [2] cn=ldapsync,c=se
=> dn: [3] cn=syncrepl1,c=se
=> dn: [4] 
=> dn: [5] 
=> dn: [6] cn=monitor
=> dn: [7] cn=subschema
=> acl_get: [8] attr o
=> acl_mask: access to entry "o=Bortheiry,c=SE", attr "o" requested
=> acl_mask: to all values by "", (=n) 
<= check a_dn_pat: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
<= check a_dn_pat: uid=replica,ou=system,o=domain.tld,c=se
<= check a_dn_pat: uid=syncuser,ou=system,o=domain.tld,c=se
<= aci_mask grant =rsc deny =n
<= acl_mask: [3] applying +rsc (stop)
<= acl_mask: [3] mask: =rsc
=> access_allowed: write access denied by =rsc
bdb_modify: modify failed (50)
----- s n i p -----

The 'funny' (well, not really :) thing is that it successfully
updates the 'cn={syncrepl1,ldapsync},c=se' object (even - !! - if it actually
didn't do anything!):

----- s n i p -----
bdb_modify: cn=syncrepl1,c=se
bdb_dn2entry("cn=syncrepl1,c=se")
bdb_modify_internal: 0x000001d8: cn=syncrepl1,c=se
acl: no-user-mod syncreplCookie: modify access granted
acl: no-user-mod structuralObjectClass: modify access granted
acl: no-user-mod entryUUID: modify access granted
acl: no-user-mod creatorsName: modify access granted
acl: no-user-mod createTimestamp: modify access granted
acl: no-user-mod entryCSN: modify access granted
acl: no-user-mod modifiersName: modify access granted
acl: no-user-mod modifyTimestamp: modify access granted
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
bdb_modify_internal: replace
=> key_change(ADD,1d8)
bdb_idl_insert_key: 1d8 [da66c05e]
<= key_change 0
=> key_change(ADD,1d8)
bdb_idl_insert_key: 1d8 [a93ebb8e]
<= key_change 0
=> entry_encode(0x000001d8): cn=syncrepl1,c=se
bdb_modify: updated id=000001d8 dn="cn=syncrepl1,c=se"
----- s n i p -----


----- s n i p -----
pumba:~# diff -u /tmp/ldapsync-before_update.ldif /tmp/ldapsync-after_update.ldif 
--- /tmp/ldapsync-before_update.ldif    Thu Jan  6 19:33:01 2005
+++ /tmp/ldapsync-after_update.ldif     Thu Jan  6 19:34:48 2005
@@ -4,6 +4,6 @@
 objectClass: syncProviderSubentry
 structuralObjectClass: subentry
 cn: ldapsync
-contextCSN: 20050106163256Z#000002#00#000000
 subtreeSpecification: {}
+contextCSN: 20050106183410Z#000001#00#000000
pumba:~# diff -u /tmp/syncrepl1-before_update.ldif /tmp/syncrepl1-after_update.ldif 
--- /tmp/syncrepl1-before_update.ldif   Thu Jan  6 19:33:37 2005
+++ /tmp/syncrepl1-after_update.ldif    Thu Jan  6 19:35:05 2005
@@ -2,8 +2,14 @@
 objectClass: top
 objectClass: subentry
 objectClass: syncConsumerSubentry
-structuralObjectClass: subentry
 cn: syncrepl1
-syncreplCookie: csn=20050106163256Z#000002#00#000000
 subtreeSpecification: {}
+syncreplCookie: csn=20050106183410Z#000001#00#000000
+structuralObjectClass: subentry
+entryUUID: 500cd6ca-f45d-1028-974b-ccdcf43f8922
+creatorsName: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
+createTimestamp: 20050106183415Z
+entryCSN: 20050106183415Z#000001#00#000000
+modifiersName: uid=replicator,cn=domain.tld,cn=gssapi,cn=auth
+modifyTimestamp: 20050106183415Z
----- s n i p -----

This is the exact same, broken behaviour I see when using
slurpd. Replication does NOT take place, but all 'evidence'
of this vanishes and slapd/slurpd pretends that all is well...
-- 
Cocaine nitrate smuggle SDI CIA munitions Saddam Hussein Semtex Panama
cryptographic Cuba radar Ft. Bragg colonel domestic disruption
[See http://www.aclu.org/echelonwatch/index.html for more about this]