openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5817) ldapadd crashes with '-' in input
by ando＠sys-net.it 18 Nov '08

18 Nov '08

jsafrane(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.4.12 > OS: Linux (Fedora 9) > URL: > Submission from: (NULL) (89.102.11.105) > > > ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion > `str != ((void *)0)' failed.' on following input: > > dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com > nismapname: netgroup.byhost > objectClass: top > objectClass: nisMap > - > > The reason is probably at ldapmodify.c:445, where the lines containing dash are > skipped, apparently for modify operations: > > if ( line[0] == '-' && !line[1] ) { > BER_BVZERO( btype+i ); > freeval[i] = 0; > continue; > } > > ldap_add_ext() seems not to like these empty spaces. I think the fix belongs to ldap_add_ext(), as other applications may well call it with invalid parameters. I've applied a fix to HEAD code, please test. The fix is Checking in libraries/libldap/add.c; /repo/OpenLDAP/pkg/ldap/libraries/libldap/add.c,v <-- add.c new revision: 1.32; previous revision: 1.31 It hould apply straightforwardly to the release you're using. Thanks, 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

(ITS#5817) ldapadd crashes with '-' in input
by jsafrane＠redhat.com 18 Nov '08

18 Nov '08

Full_Name: Jan Safranek Version: 2.4.12 OS: Linux (Fedora 9) URL: Submission from: (NULL) (89.102.11.105) ldapadd crashes with assertion 'ldapadd: encode.c:392: ber_put_string: Assertion `str != ((void *)0)' failed.' on following input: dn: nisMapName=netgroup.byhost,dc=my-domain,dc=com nismapname: netgroup.byhost objectClass: top objectClass: nisMap - The reason is probably at ldapmodify.c:445, where the lines containing dash are skipped, apparently for modify operations: if ( line[0] == '-' && !line[1] ) { BER_BVZERO( btype+i ); freeval[i] = 0; continue; } ldap_add_ext() seems not to like these empty spaces. Full backtrace: (gdb) bt full #0 0x0000003ea4832215 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003ea4833d83 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000003ea482b039 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x0000000000440e0e in ber_put_string (ber=0x1573390, str=0x0, tag=18446744073709551615) at encode.c:392 __PRETTY_FUNCTION__ = "ber_put_string" #4 0x0000000000441f5e in ber_printf (ber=0x1573390, fmt=0x44b34e "s[V]N}") at encode.c:809 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffeaf5ed80, reg_save_area = 0x7fffeaf5ecc0}} s = 0x0 ss = (char **) 0x0 bv = (struct berval *) 0x7fffeaf5ecf0 bvp = (struct berval **) 0x157b718 rc = 0 i = 2 len = 0 __PRETTY_FUNCTION__ = "ber_printf" #5 0x0000000000414edd in ldap_add_ext (ld=0x15731d0, dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", attrs=0x157b6e8, sctrls=0x0, cctrls=0x0, msgidp=0x7fffeaf5ee6c) at add.c:154 ber = (BerElement *) 0x1573390 i = 2 rc = 30 id = 2 __PRETTY_FUNCTION__ = "ldap_add_ext" #6 0x0000000000406c07 in domodify (dn=0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com", pmods=0x157b6e8, pctrls=0x0, newentry=1) at ldapmodify.c:1094 msgid = 0 rc = -352981360 i = 3 j = 4474435 k = 0 notascii = 976894522 op = 0 bvp = (struct berval *) 0xa0 #7 0x00000000004063e9 in process_ldif_rec (rbuf=0x157c786 "", linenum=1) at ldapmodify.c:866 line = 0x0 dn = 0x157c714 "nisMapName=netgroup.byhost,dc=my-domain,dc=com" newrdn = 0x0 newsup = 0x0 rc = 0 modop = 0 expect_modop = 0 expect_sep = 0 deleteoldrdn = 1 new_entry = 1 delete_entry = 0 got_all = 0 pmods = (LDAPMod **) 0x157b6e8 lm = (LDAPMod *) 0x157b6a0 version = 0 pctrls = (LDAPControl **) 0x0 i = 5 j = 3 k = 6 lines = 5 idn = 1 nmods = 3 btype = (struct berval *) 0x157b5d0 vals = (struct berval *) 0x157b630 bvl = (struct berval **) 0x157b708 bv = {bv_len = 0, bv_val = 0x0} freeval = 0x157b690 "" mops = (unsigned char *) 0x0 #8 0x000000000040458b in main (argc=11, argv=0x7fffeaf5f178) at ldapmodify.c:341 rbuf = 0x157c710 "dn" rejbuf = 0x0 rejfp = (FILE *) 0x0 ldiffp = (struct LDIFFP *) 0x1572e50 ldifdummy = {fp = 0x0, prev = 0x0} matched_msg = 0x4473c0 "H\211l$�L\211|$�H\215-/\034!" error_msg = 0x0 rc = 0 retval = 0 len = 32767 i = 0 lineno = 1 nextline = 6 lmax = 4147 c = {{ldctl_oid = 0x7fffeaf5f020 "\214�|�����3\020", ldctl_value = {bv_len = 226974810936, bv_val = 0x3ea480ae20 "\016\001"}, ldctl_iscritical = 0 '\0'}}

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

Sorry the command to create the initial database is not slapadd -f configdb -l initialdatabase.ldif but slapadd -F configdb -l initialdatabase.ldif

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 18 Nov '08

18 Nov '08

OK, my mistake, here follows a completely detailed description. * I have a slapd.conf as follows -----------------begin slapd.conf include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to dn=cn=manager,c=fr by self write by * none access to * by self write by users read by anonymous read by * none database bdb suffix "c=fr" rootdn "cn=manager,c=fr" cachesize 20000 checkpoint 10000 10 directory db index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub -----------------end slapd.conf * I convert this slapd.conf to a configdb: slapd -f slapd.conf -F configdb * I stop slapd. * I create the initial database with the following LDIF file: -----------------begin initial database dn: c=fr objectClass: country c: fr dn: cn=manager,c=fr objectClass: person cn: manager sn: manager userPassword:: c2VjcmV0 dn: cn=user,c=fr objectClass: person cn: user sn: user userPassword:: dXNlcg== dn: cn=user2,c=fr objectClass: person cn: user2 sn: user2 userPassword:: dXNlcjI= -----------------end initial database slapadd -f configdb -l initialdatabase.ldif * I edit olcDatabase={0}config.ldif file to replace olcRootDN: cn=config by olcRootDN: cn=manager,c=fr * I start slapd slapd -d 256 -F configdb * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine. * I perform the ldap modifications with this LDIF file: -----------------begin LDAP modifications dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none dn: olcDatabase={0}config,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by * none -----------------end LDAP modifications ldapmodify -x -D cn=manager,c=fr -w secret -f LDAPmodifications.ldif * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + I get: ldap_bind: Invalid credentials (49) * I stop slapd I get: filter_free: unknown filter type=19008 filter_free: unknown filter type=13304 slapd stopped. filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 filter_free: unknown filter type=13744 filter_free: unknown filter type=1264 and slapd crashes. * I restart slapd * I try to bind : ldapsearch.exe -x -D cn=manager,c=fr -w secret -s base -b "" objectclass=* + It works fine.

1 0

(ITS#5816) back-ldap stops searching if send_search_entry() returns harmless errors (like insufficientAccess)
by ando＠sys-net.it 17 Nov '08

17 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando To trigger: define acls that block one entry, and the search will stop at that entry. A fix is coming... p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 17 Nov '08

17 Nov '08

Hi Howard, Sorry for being back again but I think that a residue of the problem of whole tree scanning persists : The improvement is that it only happens once if the mirrors are not synchronized (the later statups are OK). I uploaded the new archive file ITS_5640_new.tar.gz to the FTP server (incoming directory). To reproduce the problem y can proceed as explained in folowwup 9. Thanks Best Regards Ali

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 17 Nov '08

17 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. current work-around is to set "idletimeout" in openldap shorter than mysql's "wait_timeout" (default 8hrs).

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 17 Nov '08

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > I'm sorry, but I don't. > cn=manager,c=fr was already the rootdn of config database (as well as rootdn > of c=fr database) before doing the test, with no rootpw in the config > database. > My first test consisted in modifying both olcAccess and olcRootDn for all > databases (if present) without changing any value (replacing the existing > values with the same ones). Then I made another test, with olcAccess > modifications only (on both frontend and config databases), and the problem > still appears. It only appears if I modify olcAccess of both databases, and > in this order: frontend then config. Well, I simply followed what you described in your bug report (at least what I understood). Next time, please provide a full featured script that fires up slapd and performs the offending writes. I'll change "cannot reproduce" to "report obscure". 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

RE: (ITS#5805) Problem when modifying access control
by h.b.furuseth＠usit.uio.no 17 Nov '08

17 Nov '08

Please post your configuration (minus any passwords) so it's possible to test what you are doing. Makes for less guesswork too. -- Hallvard

1 0

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I'm sorry, but I don't. cn=manager,c=fr was already the rootdn of config database (as well as rootdn of c=fr database) before doing the test, with no rootpw in the config database. My first test consisted in modifying both olcAccess and olcRootDn for all databases (if present) without changing any value (replacing the existing values with the same ones). Then I made another test, with olcAccess modifications only (on both frontend and config databases), and the problem still appears. It only appears if I modify olcAccess of both databases, and in this order: frontend then config. > > You do, since you modify the configuration using the cn=config rootdn in > order to modify itself, and set it to cn=manager,c=fr. So in the first > place you had a rootdn in cn=config, with a rootpw. And the > modification you posted did not remove the rootpw.

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