openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote: > Hold on. Is the current behavior self-consistent, i.e. one could call > it an undocumented feature? If so someone may have noticed this and > written their ACLs accordingly. It's not friendly to change the > meaning of existing installations' ACLs in the middle of RE24. > > OTOH if current behavior is broken even as a "feature", fix away. > E.g. if clients can choose which ACLs will apply in the subordinate > by picking a base DN inside vs outside the subordinate. From my analyzis of the problem, the subordinate ACLs are used in all cases except when syncprov desides which "live" modifications it should replicate to its consumers. Searching with the credentials used by the syncrepl consumer gives me the attributes and entries my subordinate ACLs allows, and they are replicated during the refresh phase. But access to entries and/or attributes being modified during the persistent phase are rejected. But yes, the change should be analyzed by somebody else before being included in a release. Rein

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by h.b.furuseth＠usit.uio.no 02 Feb '10

02 Feb '10

Hold on. Is the current behavior self-consistent, i.e. one could call it an undocumented feature? If so someone may have noticed this and written their ACLs accordingly. It's not friendly to change the meaning of existing installations' ACLs in the middle of RE24. OTOH if current behavior is broken even as a "feature", fix away. E.g. if clients can choose which ACLs will apply in the subordinate by picking a base DN inside vs outside the subordinate. -- Hallvard

1 0

(ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: 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. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 02 Feb '10

02 Feb '10

Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. Thanks! Hopefully I can compile & test tomorrow, I'll let you know. Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test.

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

This got introduced by the fix for ITS#6419. I am currently working on a fix.

1 0

(ITS#6467) syncrepl enhancements
by hyc＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.212) 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.

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 01 Feb '10

01 Feb '10

Sorry. 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) (193.231.233.40) >> >> >> I have a master ldap server running openldap 2.4.21 and 3 replicas >> running >> 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. >

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by masarati＠aero.polimi.it 01 Feb '10

01 Feb '10

hyc(a)symas.com wrote: >> 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. p.

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 01 Feb '10

01 Feb '10

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 >> here. > > 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 incorporated, piecemeal...) > Anyway, thank you again. I'll test the head version and will come back > later. > 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/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs