Full_Name: Rein Tollevik
Version: CVS HEAD
Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd)
Submitted by: rein
In a glued database configuration where overlays (syncprov, accesslog) are
stacked on top of the glue overlay, ACL evaluation initiated from these overlays
can be evaluated by the superior glue database and not the subordinate database
where the entry actually exist. I.e, ACLs defined in the subordinate databases
are ignored in these cases.
A fix that implements bi_access_allowed in the glue overlay is coming, it
delegates the call to the actual backend where the entry being referenced exist.
An alternative approach I considered was to require the overlays to call
select_backend() to find the actual backend where the entry exist, but that
would imo obfuscate the modularization of the code.
Full_Name: Howard Chu
Submission from: (NULL) (188.8.131.52)
Submitted by: hyc
Syncrepl refreshes can be very expensive without a sessionlog, and the syncprov
sessionlog is inadequate because it's in-memory only, and doesn't survive a
restart. Syncprov should be extended to take advantage of the accesslog overlay
if it is available.
I hope this helps: http://lthd.com/slapd.out
On 01/31/2010 01:05 AM, Howard Chu wrote:
> csdr(a)lthd.com wrote:
>> Full_Name: Chis-Serban Dinu-Razvan
>> Version: 2.4.21
>> OS: Fedora 12
>> URL: http://lthd.com/out1.txt
>> Submission from: (NULL) (184.108.40.206)
>> I have a master ldap server running openldap 2.4.21 and 3 replicas
>> 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the
>> master dies
>> with an buffer overflow error. I mention that before the master was
>> 2.4.15 and
>> the replica running 2.4.19 died. I have updated the master to 2.4.19
>> and it
>> start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies
>> even if the
>> syncprov is off.
> Please provide a stack trace from this crash. Be sure to compile with
> debug symbols enabled and no optimization, otherwise we won't be able
> to track anything down.
>> BTW, what do you mean by "needs some thought" (in the ticket notes)?
> I hadn't decided yet if slapd should log a warning for this or not.
A warning, to be useful, should allow to clearly identify the broken
piece of data. Where the issue is identified, there's no way to find
out the DN of the entry that contains the datum. All you could use is
the certificate's content (e.g. issuer DN and so); not sure how helpful
it would be.
Erwann Abalea wrote:
> Hodie III Kal. Feb. MMX, Howard Chu scripsit:
(Sorry, just had to laugh, using a ~3000 year old language in email...)
>> erwann.abalea(a)keynectis.com wrote:
>> Also note that, technically, LDAP is defined to conform to the 1993
>> edition of the X.500 specs, and X.509(1993) makes no such allowance
> I didn't know that LDAP was designed to conform to a specific edition
> of the standard. Isn't that strange? After all, it should also refuse
> to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the
> first time in the 1997 edition.
> Anyway, I hadn't thought about looking at older revisions of the X.509
> standard. You're right, my 1997 edition doesn't say anything about
> this, and my 2000 edition (a french version) has the same text as the
> 2005 one.
See RFC4510, section 2. Yes, it's certainly an inconsistency in the LDAP spec,
that RFC4513 requires use of subjectAltNames which clearly require X.509v3
certs but the only normative references to the necessary edition of X.509 is
outside the core specification. (Looking again I see that RFC4523 references
X.509(2000) so it appears that some portions of newer X.500 editions are being
> Anyway, thank you again. I'll test the head version and will come back
> BTW, what do you mean by "needs some thought" (in the ticket notes)?
I hadn't decided yet if slapd should log a warning for this or not.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Hodie III Kal. Feb. MMX, Howard Chu scripsit:
> erwann.abalea(a)keynectis.com wrote:
> >When no certificate is revoked, the revokedCertificate element SHOULD be
> >omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has
> >changed the SHOULD into a MUST, but I don't think this is checked by the
> >function. I think it only skips over the next element (in my case, the
> Thanks for the report. The code in CVS HEAD has been patched to
> silently accept this case. However, it's worth pointing out that
> even in X.509(2005):
Thank you for having corrected it.
> If none of the certificates covered by this CRL have been revoked,
> it is strongly recommended that
> revokedCertificates parameter be omitted from the CRL, rather than being
> included with an empty SEQUENCE.
That's what I meant to write when I wrote that the element SHOULD be
omitted. X.509 doesn't prevent such an empty sequence, it only
strongly recommends to avoid it. A strong recommendation in ISO
terminology is as a SHOULD in RFC2119 meaning. You're right, here.
> Also note that, technically, LDAP is defined to conform to the 1993
> edition of the X.500 specs, and X.509(1993) makes no such allowance
I didn't know that LDAP was designed to conform to a specific edition
of the standard. Isn't that strange? After all, it should also refuse
to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the
first time in the 1997 edition.
Anyway, I hadn't thought about looking at older revisions of the X.509
standard. You're right, my 1997 edition doesn't say anything about
this, and my 2000 edition (a french version) has the same text as the
> We may consider logging a warning for this case. What software
> generated this CRL? It seems to be defective...
At first, I also thought it was defective. But after all, the standard
doesn't say that this revokedCertificates element MUST be eliminated
when no certificate is revoked (I use RFC2119 terminology here, but
you certainly got it).
I certainly will produce a warning to the software vendor, though. In
general, I tend to follow "SHOULD" rules. I don't know what software
produced this CRL (yet), I only know who uses it (one of our
customers). I'll get in touch with them for that. In the same time,
I'll check that we correctly do our job (we're also a PKI software
Anyway, thank you again. I'll test the head version and will come back
BTW, what do you mean by "needs some thought" (in the ticket notes)?
Erwann ABALEA <erwann.abalea(a)keynectis.com>
"Common sense is the collection of prejudices acquired by age 18."
- Albert Einstein