openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 20 Feb '09

20 Feb '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.14/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > back-meta doesn't check the return code from the normalizer when it's > normalizing the values of an attribute. As such, it can leave NULL slots in > a->a_nvals even though a->a_vals slots are all non-NULL. This seems like an odd situation, since we just went thru the validator above, before attempting to normalize. In this case the attribute was telephoneNumber, with a value of " " (a single space). The validator is printableStringValidate, which accepts the value. But telephoneNumberNormalize rejects it. Shouldn't the validator and normalizer always accept the same set of input? Anyway, HEAD is fixed to just drop the illegal values, as Ando suggested. -- -- 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#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 20 Feb '09

20 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Looking over the code, there are some other problems. Other areas will drop values for various reasons (e.g., mapping out objectclass values). attr->a_numvals is set before these checks occur, and is not updated with the correct count later. I'll try to get some more fixes in for .15. -- -- 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#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 20 Feb '09

20 Feb '09

ando(a)sys-net.it wrote: > A patch is coming. An essential part of the fix was missing. This is now fixed in HEAD, please test. 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#5959) back-meta doesn't detect illegal values
by hyc＠symas.com 20 Feb '09

20 Feb '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> back-meta doesn't check the return code from the normalizer when it's >> normalizing the values of an attribute. As such, it can leave NULL slots in >> a->a_nvals even though a->a_vals slots are all non-NULL. >> >> I was going to try just dup'ing the a->a_vals value into the slot, but I see >> that in back-ldap for the same situation, the entire attribute is just dropped. >> I suppose that's the safer path. > > In the spirit of doing what's best to return as much as possible, > wouldn't it be preferable to just drop illegal values? And, of course, > the whole attr if no legal values are left. Sounds fine, will do that for a future rev. -- -- 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#5960) [rwm] segfault with slapcat on cn=config
by hyc＠symas.com 20 Feb '09

20 Feb '09

tchemineau(a)linagora.com wrote: > Full_Name: Thomas Chemineau > Version: RE24 and HEAD > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/thomas-chemineau-090219.patch > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Here is the following configuration : > > 8<---- > include /opt/openldap-2.4.14/etc/openldap/schema/core.schema > pidfile /opt/openldap-2.4.14/var/run/slapd.pid > argsfile /opt/openlidap-2.4.14/var/run/slapd.args > > database ldap > suffix "o=proxy" > uri ldap://server.lan > idassert-bind mode=none flags=prescriptive bindmethod=simple timeout=0 > network-timeout=0 binddn="cn=administrateur,cn=users,dc=otherdemo,dc=lan" > credentials="secret" > overlay rwm > rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > > database bdb > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /opt/openldap-2.4.14/var/openldap-data > index objectClass eq > 8<---- > > Initializing cn=config via slapd -f ... -F works fine. Now, if I want to do a > slapcat on cn=config with the following command, I had a segmentation fault. > > 8<---- > ldif_read_file: read entry file: > "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={1}ldap/olcOverlay={0}rwm.ldif" > => str2entry: "dn: olcOverlay={0}rwm > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=otherdemo,dc=lan" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > structuralObjectClass: olcRwmConfig > entryUUID: 8d7c51c4-239f-48f5-9ad5-751a50942eec > creatorsName: cn=config > createTimestamp: 20090219101010Z > entryCSN: 20090219101010.781439Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20090219101010Z > " >>>> dnPrettyNormal:<olcOverlay={0}rwm> > <<< dnPrettyNormal:<olcOverlay={0}rwm>,<olcOverlay={0}rwm> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> >>>> dnPretty:<cn=config> > <<< dnPretty:<cn=config> >>>> dnNormalize:<cn=config> > <<< dnNormalize:<cn=config> > <= str2entry(olcOverlay={0}rwm) -> 0x124cbe48 > => test_filter > PRESENT > => access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > Erreur de segmentation > 8<---- > > I run GDB, and I had this: > > 8<---=> access_allowed: search access to > "olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config" "objectClass" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 46972859751984 (LWP 9462)] > 0x00000000004e08cf in rwm_cf_gen (c=0x7ffff26060b0) at rwm.c:2165 > 2165 for ( last = 0; !BER_BVISNULL( > &rwmap->rwm_bva_rewrite[ last ] ); last++ )- > 8<---- > > It seems that rwmap->rm_bva_rewrite is null. By the way, even if I correct this, > I have a similar issue in the rwm_db_destroy function, because rwmap->rwm_rw is > null too. So, freeing memory on a null pointer causes a segfault too. The above > patch corrects this problem. My apologies if I have missed something here. > > By the way, I make a mistake during the upload file on ftp.openldap.org, you > will find 2 files (both the same): servers.slapd.overlays.rwm.c.patch and the > other one specified above. > Thanks for the report. The last chunk of the patch was solving the wrong problem, so a different fix is in HEAD. -- -- 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#5724 (Re: commit: ldap/servers/slapd backover.c)
by hyc＠symas.com 19 Feb '09

19 Feb '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Sharing the pointer to the supported controls would allow to use the >> actual set. Something along the line >> >> struct BackendDB { >> char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; >> char *be_ctrls; >> }; >> >> All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set >> it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf >> for the duration of an operation. Modules wouldn't be able to register >> new controls because the pointer is null otherwise. > > Of course, this wouldn't work since it implies modifying the BackendDB > structure, which is read-only :( backover.c 1.91 appears to partially revert rev 1.84, thus breaking ITS#5346 again. Investigating now... -- -- 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#5962) If slapcat can't join shm, it segfaults
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If the shm environment is not available, and you run slapcat, it segfaults: (gdb) bt #0 0x0000002a97256996 in hdb_tool_entry_open (be=0x70ca70, mode=0) at tools.c:108 #1 0x00000000004bb31b in slapcat (argc=7, argv=0x7fbffff8a8) at slapcat.c:73 #2 0x0000000000413274 in main (argc=7, argv=0x7fbffff8a8) at main.c:391

1 0

(ITS#5961) segfault if shm isn't available
by quanah＠OpenLDAP.org 19 Feb '09

19 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If OpenLDAP can't join the shm environment due to size issues, it segfaults: #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 192 config.c: No such file or directory. in config.c (gdb) bt #0 0x0000002a973fe32b in hdb_checkpoint (ctx=0x41000e20, arg=0x999820) at config.c:192 #1 0x0000002a95702a60 in ldap_int_thread_pool_wrapper (xpool=0x916ee0) at tpool.c:663 #2 0x0000003bfa006137 in start_thread () from /lib64/tls/libpthread.so.0 #3 0x0000003bf97c7533 in clone () from /lib64/tls/libc.so.6

1 0

OpenLDAP crashes with segfault
by Tim Stone 19 Feb '09

19 Feb '09

Hello, I've installed OpenSuse 11 on a 64bit Intel Xeon. I configured one OpenLDAP as sync provider and the second one as consumer (RefeshOnly). But every time, a change is made in the provider and the consumer try to sync, the Provider crashs with segfault. I configured a own filter in syslog so that the slapd is logging in an exra logfile. The loglevel is -1. In the logfile are no related information. In the syslog I found following line: Feb 18 13:30:35 ldap-11 kernel: slapd[6151]: segfault at 8 ip 7f18d3a7b695 sp 40a60400 error 4 in libc-2.8.so[7f18d3a04000+14f000] To debug this, I turned corefiles on: sysctl -w kernel.core_pattern=/core sysctl -w kernel.core_uses_pid = 1 ulimit -c unlimited but no corefiles are created ... Can anyone help me? Thanx !!! Here my configuration Master/Provider: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/my.schema include /etc/openldap/schema/freeRadius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules sizelimit -1 disallow bind_anon access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self auth by anonymous auth by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none access to dn.subtree="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none loglevel -1 TLSCertificateFile /etc/openldap/certs/ldapmcrt.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSCertificateKeyFile /etc/openldap/certs/ldapmkey.pem database bdb monitoring off suffix "dc=mydom,dc=local" checkpoint 1024 5 rootdn "uid=administrator,dc=mydom,dc=local" rootpw "{SSHA}xxxxxxxxxxxx" directory /var/lib/ldap index objectClass,entryUUID,entryCSN,uid,cn eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Here my configuration Slave/Consumer: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/my.schema include /etc/openldap/schema/freeRadius.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules sizelimit -1 disallow bind_anon access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword by self auth by anonymous auth by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none access to dn.subtree="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" by dn="uid=replica,ou=specialusers,ou=_management,dc= mydom,dc=local" read by * none loglevel -1 TLSCertificateFile /etc/openldap/certs/ldapscrt.pem TLSCACertificateFile /etc/openldap/certs/cacert.pem TLSCertificateKeyFile /etc/openldap/certs/ldapskey.pem database bdb monitoring off suffix "dc=mydom,dc=local" checkpoint 1024 5 rootdn "uid=administrator,dc=mydom,dc=local" rootpw "{SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" directory /var/lib/ldap index objectClass,entryUUID,entryCSN,uid,cn eq syncrepl rid=124 provider=ldap://ldapm:389 binddn=uid="fradius_replica,ou=specialusers,ou=_ma nagement,dc=mydom,dc=local" credentials="secretpass" type=refreshOnly interval=00:00:00:30 retry="60 10 300 3" searchbase="ou=freeRadius,ou=systeme,ou=PDB,dc=myd om,dc=local" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple starttls=critical

2 1

Debug mode "fixes" authentication issue - race condition?
by Neil Garratt 19 Feb '09

19 Feb '09

Hi I'm testing OpenLDAP 2.3.27 (RPM) on Centos 5.2, used as a reverse proxy to AD. When slapd is run with debugging disabled (or set to 0), search requests throw the following error: DSID-0C090627: In order to perform this operation a successful bind must be completed on the connection. When run with any other debug value, it returns the results correctly. In both cases, the logs show a successful bind with the acl-bind user, the search finds the correct result, and acl's show access granted to read. The only difference is what is returned Non-working: Feb 19 11:17:20 localhost slapd[2916]: conn=0 op=1 ENTRY dn="cn=neil garratt,ou=admins,ou=users,ou=cape town,ou=networks unlimited,dc=nu,dc=local" Feb 19 11:17:20 localhost slapd[2916]: <= send_search_entry: conn 0 exit. Feb 19 11:17:20 localhost slapd[2916]: send_ldap_result: conn=0 op=1 p=3 Feb 19 11:17:20 localhost slapd[2916]: send_ldap_result: err=1 matched="" text="00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece" Feb 19 11:17:20 localhost slapd[2916]: send_ldap_response: msgid=2 tag=101 err=1 Feb 19 11:17:20 localhost slapd[2916]: conn=0 op=1 SEARCH RESULT tag=101 err=1 nentries=1 text=00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Working: Feb 19 11:18:42 localhost slapd[2949]: conn=0 op=1 ENTRY dn="cn=neil garratt,ou=admins,ou=users,ou=cape town,ou=networks unlimited,dc=nu,dc=local" Feb 19 11:18:42 localhost slapd[2949]: <= send_search_entry: conn 0 exit. Feb 19 11:18:42 localhost slapd[2949]: send_ldap_result: conn=0 op=1 p=3 Feb 19 11:18:42 localhost slapd[2949]: send_ldap_result: err=0 matched="" text="" Feb 19 11:18:42 localhost slapd[2949]: send_ldap_response: msgid=2 tag=101 err=0 Feb 19 11:18:42 localhost slapd[2949]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd.conf: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth loglevel any database ldap suffix "dc=nu,dc=local" uri "ldap://cptdc1.nu.local" acl-bind bindmethod=simple binddn="CN=LDAP,OU=Service Accounts,DC=nu,DC=local" credentials="xxxxxxxxxxxx"

2 1

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