Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue

[ryans@aweber.com]

Ryan Steele wrote:
> Actually, it would appear I'm hitting the same problem as the OP in this thread:
> 
> http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require
> authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results
> 
> 
> I say that because when I get prompted for authentication by the slave (instead of having the referral handled
> server-side), I see this corresponding entry in the master's logs:
> 
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389)
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text=
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND
> May  4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed
> 
> 
> So, it looks like the DN is not being passed through for some reason.  Still working on trying to track it down...
> 


The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the
directory), so it's not just third party utilities.  It really does appear as though the chain overlay is stripping the
DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the
master and fails because there is no DN before a referral is presented to the client that initially sent the update to
the slave.  I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't
being denied by ACL's or anything like that.


I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ
(http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not
think that they are required or causing this problem.  In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the
slaves (as the FAQ says) just to be absolutely sure, but it made no difference.


I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just
prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that
you made, Pierangelo.  In either case, the behavior is broken.  Exactly where, I'm still trying to figure out, but would
definitely appreciate any input from more seasoned OpenLDAP developers.