openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 14 Apr '10

14 Apr '10

rhafer(a)suse.de wrote: > Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: >> rhafer(a)suse.de wrote: >>> Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >>>> But how did the suffix entry get created without an entryCSN in the >>>> first place? The MOD that updates the contextCSN doesn't happen >>>> until after the suffix entry already exists. >>> >>> It wasn't created without an entryCSN. It always had one. But the >>> MOD to update the contextCSN (coming from the provider) doesn't >>> contain one. So bdb_modify() will call slap_mods_opattrs() to add >>> entryCSN to the MOD operation. The easiest fix is probably to never >>> touch the opattrs if "updatedn" is doing MODs, though I am not yet >>> sure if it might break something. Currently my fix (not committed >>> yet) only skips the slap_mods_opattrs() step if "updatedn" it is >>> doing a MOD on contextCSN. >> >> Ah, got it. Yes, sounds like your fix is fine. > Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" > is writing? Or should I check for contextCSN MODs specifically? > >> Historically the updatedn user (e.g. slurpd) has always provided all of >> the operational attributes in its updates. > I guess the question is what have we done in the past for updatedn writes? If we filled in missing opattrs, then we should continue to do so. So it should be a special case for contextCSN mods. -- -- 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

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> --Boundary-00=_glFxL04kLcJl7l6 > Content-Type: Text/Plain; > charset="iso-8859-15" > Content-Transfer-Encoding: quoted-printable > > Thanks for your quick answer Pierangelo, > > On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: >> > [...] >> > My guess is that you're trying to use ACIs with a non-local storage. >> In >> > that case your analysis is correct. Can you provide your (sanitized) >> > configuration? > > I am using a local hdb backend. > > In order to generate a minimal test case I found out, that it seems to > be=20 > related to the rwm overlay. > > Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 > active. > Commenting out the rwm directives completely makes the searches work as=20 > expected. > > Please find attached a testcase with slapd.conf and ldif data. > To experience the issue simply perform a search with e.g. attribute 1.1 as > = > one=20 > of the users in the data. > Then comment the rwm-... lines in slapd.conf, restart slapd and try again. > Voil=E0 the difference. I see. probably, a relatively "quick" fix would be to allow to define a list of attributes, specific for a database, that is available to all implementations that need to muck with requested attrs (e.g. slapd-ldap, slapd-meta, slapo-rwm). They are supposed to be added to the list of requested attrs whenever appropriate. It's up to the administrato to keep it updated with everything that may be needed by special features like ACI. Something like required_attrs OpenLDAPACI In the future, we might be able to figure out a clever way to self-detect what attributes need to be treated this way. I'll work at that, time permitting. Thanks for reporting. p.

1 0

(ITS#6523) idassert marks proxyAuthz as non-critical
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando RFC 4370 requires the criticality flag to be present and set to TRUE. I also note that slapd by default tolerates this behavior, and provides the disallow proxy_authz_non_critical directive to behave in strict accordance with RFC 4370. I've introduced a corresponding proxy-authz-[non-]critical flag in idassert. p.

1 0

Re: (ITS#6518) Slapd-ldap proxy between replica and mirror
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

> We have problems when we introduce a back-ldap proxy server between a > delta-syncrepl server and a mirror configuration of two servers. > > The modifications through the replica server (with chaining configuration) > over > the first mirror server are made without problems. The problem appears > when we > introduce a back-ldap proxy between replica and the two servers in mirror > mode. I've already fixed the bit of this issue related to not being able to process ordered attributes in proxies (ITS#6516). This is required to retrieve attributes authzFrom and authzTo, used by the proxy authorization process. The rest of your issue is related to the fact that the slave uses proxyAuthz to propagate the modify request to the updateref server. When this is a proxy, it needs to add proxyAuthz itself to correctly proxy the operation to the master. But two proxyAuthz controls are not allowed. You'd need to use distributed procedures, which are not implemented in OpenLDAP. A distributed operation would then consist in an extended operation that wraps the original one into a new request, with its own controls. At this point, proxyAuthz could apply incrementally at each layer. I'd treat your ITS as yet another request to implement distributed procedures. p.

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by hyc＠symas.com 14 Apr '10

14 Apr '10

rein(a)OpenLDAP.org wrote: > 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. The fix seems to head in the right direction. One could argue that the correct behavior is to apply the subordinate's ACLs first, and then check the parent's ACLs, and then finally any global ACLs. -- -- 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

(ITS#6522) man page for pcache overlay doesn't state requirement for rootdn
by jonathan＠phillipoux.net 14 Apr '10

14 Apr '10

Full_Name: Jonathan Clarke Version: current RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-man-20100414.patch Submission from: (NULL) (82.127.99.208) In the code for the pcache overlay, there is a comment stating: /* Cached database must have the rootdn */ And trying to configure the pcache overlay on a database without rootdn, via slapd.conf, produces errors like: pcache_db_open(): underlying database of type "ldap" serving naming context "o=passwd" has no "rootdn", required by "pcache". However, the pcache man page doesn't mention this. I suggest the patch above.

1 0

(ITS#6521) docs: pcache overlay section in admin guide
by jonathan＠phillipoux.net 14 Apr '10

14 Apr '10

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jcl-admin-guide-overlays-20100414.patch Submission from: (NULL) (82.127.99.208) The section of the admin guide on the proxy cache overlay is a little out of date. The patch below: - updates deprected keywords to their new names (s/proxyAttrset/pcacheAttrset/, etc) - adds a configuration example for back-config, which is not trivial to guess

1 0

Re: (ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 14 Apr '10

14 Apr '10

--On Tuesday, April 13, 2010 9:22 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, April 13, 2010 9:07 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Here is the -d -1 output from the provider during this time period. You > can clearly see part way through where the empty cookie is sent after a > delete operation is completed. I can confirm Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays Modified Files: accesslog.c 1.105 -> 1.106 Log Message: ITS#6519 don't replicate purge deletes CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/accesslog.c Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed. fixes the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6520) ACL bug with various .expand styles
by masarati＠aero.polimi.it 14 Apr '10

14 Apr '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6376) memleak in 2.3
by jonathan＠OpenLDAP.org 14 Apr '10

14 Apr '10

On 14/11/2009 05:21, mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.3 only > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > In 2.3, if you have a lot of fast writes such that syncprov_sendresp's > op tmp memory is exhausted and it has resorted to malloc()s AND > controls are asserted, the rs.sr_ctrls free at the end of the function > leaks. > > To duplicate: Set up a master and a replica. Do mods like crazy with > some control asserted, e.g. manageDSAIT. > > 2.4/head handle this differently so it isn't a problem there. Hi, This ITS says 2.3 only, but it is listed in the changelog for 2.4.20. Did this also affect versions on the 2.4 branch < 2.4.20, then? Just checking for bug fixes and came across this inconsistency. Any enlightenment welcome. Jonathan

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010