openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by hyc＠symas.com 01 Aug '08

01 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > After upgrading to 2.4.11 all our LDAP servers would abort when modifications > were made to them. Here are the last messages leading up to and including the > abort: This appears to be the same as ITS#5581. Please direct all further emails to that item instead. It looks like there's a problem in your slapo-unique configuration. > > => bdb_list_candidates 0xa0 > => bdb_filter_candidates > OR > => bdb_list_candidates 0xa1 > => bdb_filter_candidates > EQUALITY > => bdb_equality_candidates (objectClass) > => key_read > bdb_idl_fetch_key: [b49d1940] > <= bdb_index_read: failed (-30989) > <= bdb_equality_candidates: id=0, first=0, last=0 > <= bdb_filter_candidates: id=0 first=0 last=0 > => bdb_filter_candidates > <= bdb_filter_candidates: id=0 first=0 last=0 > <= bdb_list_candidates: id=0 first=0 last=0 > <= bdb_filter_candidates: id=0 first=0 last=0 > <= bdb_list_candidates: id=0 first=1 last=0 > <= bdb_filter_candidates: id=0 first=1 last=0 > bdb_search_candidates: id=0 first=1 last=0 > bdb_search: no candidates > send_ldap_result: conn=7 op=13 p=3 > send_ldap_result: err=0 matched="" text="" > => unique_search found 0 records > ==> unique_search > str2filter "(&(?=error)(|))" > put_filter: "(&(?=error)(|))" > put_filter: AND > put_filter_list "(?=error)(|)" > put_filter: "(?=error)" > put_filter: simple > put_simple_filter: "?=error" > => bdb_search > bdb_dn2entry("dc=fam") > => access_allowed: search access to "dc=fam" "entry" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > search_candidates: base="dc=fam" (0x00000001) scope=2 > Assertion failed: (f != NULL), function oc_filter, file search.c, line 970. > Abort trap: 6 -- -- 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#5635) slapi SLAPI_MODIFY_MODS mod->mod_op offset.
by hyc＠symas.com 01 Aug '08

01 Aug '08

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.10 > OS: Linux/F9 > URL: > Submission from: (NULL) (138.37.8.59) > > > In a slapi pre-modify function (SLAPI_PLUGIN_PRE_MODIFY_FN) you can get a null > terminated array of LDAPMod modifications. Like so: > > /* get list of mods */ > if (slapi_pblock_get(pb,SLAPI_MODIFY_MODS,&mods) || !mods) { > LOG("[%i] Error retrieving LDAPMods.\n",conn_id); > return (PLUGIN_STOP); > } > DEBUG("[%i] Got LDAPMods.",conn_id); > > > If you loop over these and extract the mod_op values which are held in > mod->mod_op, the values seem to be offset by 128. i.e. an add operation, which > should have a value of 0 (LDAP_MOD_ADD) has a value of 128. A delete operation, > should have 2 (LDAP_MOD_DELETE) it seems to be set to 130. > > The numbers differ only in the 8th bit. So I'm wondering if there is a strange > signed/unsigned int conversion thing going on somewhere. That's the LDAP_MOD_BVALUES flag. There's no bug here, this ITS will be closed. -- -- 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#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by stef＠memberwebs.com 01 Aug '08

01 Aug '08

Full_Name: Stef Version: 2.4.11 OS: FreeBSD 6.3-RELEASE-p2 URL: Submission from: (NULL) (38.99.5.20) After upgrading to 2.4.11 all our LDAP servers would abort when modifications were made to them. Here are the last messages leading up to and including the abort: => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=1 last=0 <= bdb_filter_candidates: id=0 first=1 last=0 bdb_search_candidates: id=0 first=1 last=0 bdb_search: no candidates send_ldap_result: conn=7 op=13 p=3 send_ldap_result: err=0 matched="" text="" => unique_search found 0 records ==> unique_search str2filter "(&(?=error)(|))" put_filter: "(&(?=error)(|))" put_filter: AND put_filter_list "(?=error)(|)" put_filter: "(?=error)" put_filter: simple put_simple_filter: "?=error" => bdb_search bdb_dn2entry("dc=fam") => access_allowed: search access to "dc=fam" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) search_candidates: base="dc=fam" (0x00000001) scope=2 Assertion failed: (f != NULL), function oc_filter, file search.c, line 970. Abort trap: 6

1 0

(ITS#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by kouk＠noc.uoa.gr 01 Aug '08

01 Aug '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080801.diff Submission from: (NULL) (195.134.100.30) There is a bug in the function 'slap_acl_mask' in servers/slapd/acl.c that affects the processing of dynacls. In particular the code attempts to apply ACL_ACCESS2PRIV to a variable already containing a slap_mask_t value. By chance this does not make a difference except when the dynacl rule is applied after a 'break' in a previous rule that has altered the default mask. It appears that the intention was to check whether the requested access level applies to the dynacl rule access mask. Instead the check is made against the current applied mask. The referenced patch fixes this issue by passing the requested access level as an extra parameter to the function and using it for the check.

1 0

(ITS#5636) performance improvement in ACI evaluation
by stef＠noc.uoa.gr 01 Aug '08

01 Aug '08

Full_Name: Stefanos Stamatis Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/stefanos-stamatis-080801.diff Submission from: (NULL) (195.134.100.30) The function 'aci_mask' in servers/slapd/aci.c will evaluate the type and subject part of an ACI even if the 'action;rights;attr;' part of the ACI does not apply. This is bad for performance, especially if the subject is a set which dereferences the objects 'user' or 'this'. The referenced patch solves this issue by fixing 'aci_list_get_rights' to return 0 if the returned mask does not effect a change.

1 0

(ITS#5635) slapi SLAPI_MODIFY_MODS mod->mod_op offset.
by m.d.t.evans＠qmul.ac.uk 31 Jul '08

31 Jul '08

Full_Name: Martin Evans Version: 2.4.10 OS: Linux/F9 URL: Submission from: (NULL) (138.37.8.59) In a slapi pre-modify function (SLAPI_PLUGIN_PRE_MODIFY_FN) you can get a null terminated array of LDAPMod modifications. Like so: /* get list of mods */ if (slapi_pblock_get(pb,SLAPI_MODIFY_MODS,&mods) || !mods) { LOG("[%i] Error retrieving LDAPMods.\n",conn_id); return (PLUGIN_STOP); } DEBUG("[%i] Got LDAPMods.",conn_id); If you loop over these and extract the mod_op values which are held in mod->mod_op, the values seem to be offset by 128. i.e. an add operation, which should have a value of 0 (LDAP_MOD_ADD) has a value of 128. A delete operation, should have 2 (LDAP_MOD_DELETE) it seems to be set to 130. The numbers differ only in the 8th bit. So I'm wondering if there is a strange signed/unsigned int conversion thing going on somewhere. For info, I need to do the following to fix those values in my slapi code so that my comparisons of mod->mod_op match the #defined macros LDAP_MOD_(ADD|DELETE|&c): while((mod=*mods)){ /* workaround for bad mod_op values */ if(mod->mod_op>127){ DEBUG("[%i] mod_op value (%i) is offset, fixing.",conn_id,mod->mod_op); mod->mod_op-=128; } if(mod->mod_op==LDAP_MOD_ADD) { ... } } Thought I'd report it. Cheers, Martin.

1 0

(ITS#5634) str2entry NULL (smr_normalize reqControls 21) when slapadding accesslog-DB with reqControls
by michael＠stroeder.com 30 Jul '08

30 Jul '08

Full_Name: Michael Ströder Version: RE24 OS: Linux URL: Submission from: (NULL) (84.163.81.95) I tried to restore an accesslog reqControls: {0}{2.16.840.1.113730.3.4.2} <= str2entry NULL (smr_normalize reqControls 21) slapadd: could not parse entry (line=6) Ciao, Michael.

1 0

Slapd terminates unexpectedly
by Craig Worgan 26 Jul '08

26 Jul '08

Hello, I am running OpenLDAP 2.3.42 on Windows as a service and am experiencing very frequent cases where the slapd service terminates unexpectedly. I run the same OpenLDAP load on Redhat Linux where I have had only a single (unconfirmed) report of slapd stopping on its own. I suspected that the problem may be related to the Windows Service Manager, so I ran a slapd instance from the command line to remove WSM from the equation. I was able to reproduce the problem twice, each time the console printed the following message: Assertion failed: sd == AC_SOCKET_INVALID, file connection.c, line 288 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. I am currently running slapd in the console with full debugging turned on, but as of yet haven't seen the problem. I will forward a more complete trace if I can capture one. I have been running various version of OpenLDAP on Windows in this manner for the past 4 years without problems. Recently, I started using syncrepl and PPOLICY. I don't think this is related to my problem, but thought it worth noting. Thanks, Craig Worgan

2 1

Re: (ITS#5632) "overlay" directive listing in slapd.conf misleading
by hyc＠symas.com 25 Jul '08

25 Jul '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The "overlay" directive in slapd.conf is listed under "general database > options", but it can in fact be global, depending on the overlay. At least the > wording in slapd.conf for this directive should be updated to reflect that. The majority of overlays don't work as globals. Since those that do are the exception, it's probably better to just note these exceptions on the individual slapo- manpages. A lot more would need to be reworked to really describe things accurately; there are in fact no global overlays at all. Just that some of them work when attached to the frontendDB database. And the frontendDB was created after overlays were first designed; the docs just haven't caught up to this fact yet. -- -- 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#5633) slapo-retcode manpage
by ando＠sys-net.it 25 Jul '08

25 Jul '08

----- quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The slapo-retcode man page has this as the example: > > overlay retcode > retcode-parent "ou=RetCodes,dc=example,dc=com" > include ./retcode.conf > > # Wait 10 seconds, then return success (0x00) > retcode-item "cn=Success after 10 seconds" 0x00 > sleeptime=10 > # Wait 10 seconds, then return timelimitExceeded (0x03) > retcode-item "cn=Timelimit after 10 seconds" 0x03 > sleeptime=10 > > > I think the "include" bit there is a mistake, and the following lines > were the > contents of it? Not sure about that (don't recall writing that example, at least) but a retcode.conf actually exists, and contains declarations for LDAP (and LDAPish) errors. The additional lines provide extra declarations for errors that are returned only after sleeping 10 seconds, to test client's resilience to delays or intermediate timeouts. So the two things are not incompatible. Of course, the example could clarify where retcode.conf can be found, if it is installed at all. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

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