openldap-bugs May 2011

openldap-bugs@openldap.org

33 participants
70 discussions

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 05 May '11

05 May '11

quanah(a)zimbra.com wrote: > --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> hyc(a)symas.com writes: >>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >> >> There are several fopen(filename, "w") calls, which truncate the file. >> Maybe the error confuses slapd so it takes a detour into one of them. Irrelevant. In Windows the OS prevents you from writing to an executable file that is currently running. I.e., it is impossible for this to be the cause. Try it yourself: #include <stdio.h> main(int argc, char *argv[]) { FILE *f=fopen(argv[0], "w"); if (f) printf("opened!\n"); else printf("failed!\n"); } >> Quanah, can you provide a full slapd.conf and command line which causes >> this? Not that I have a Windows box to test it on, but still... > > The command line was just slapd.exe -d -1 -f slapd.conf > > The slapd.conf itself is fairly small. The line that wrapped was the > include for inetOrgPerson. Everything obviously stopped when it hit the > wrapped include. > > ucdata-path "/opt/zimbra/openldap/ucdata" > include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" > include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" > include > "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" Yes, but since "everything obviously stopped" there's nothing in slapd that fopen's any files from that point. First of all this problem cannot be specific to the include statement, since the input validation will reject the line before ever going anywhere the code for include handling. So, you ought to be able to reproduce this issue using any config statement that requires a single argument. Second, slapd stops all parsing and simply exits when it hits a config error. And this is early enough in the config file that nothing else has been initialized yet, so the teardown processing has very little to do. If you still believe it's happening inside slapd the obvious thing to do to track this is to run slapd under gdb and set a few breakpoints. E.g., one at the end of the config parser, and one at slapd's call to exit(). At each breakpoint, check the filesize of the slapd.exe. -- -- 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#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

The root cause in this case is that the schema differs on the consumer and schema violation errors were logged at the consumer. Obviously this is a configuration error but the provider should not crash because of this!

1 0

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

1 0

Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com 04 May '11

04 May '11

ryans(a)aweber.com wrote: > Full_Name: Ryan Steele > Version: 2.4.23 > OS: Ubuntu Server 10.04 (Lucid) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle > Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet > attribute, populating it with a value that does not take DST into account. As > an example, consider the following attributes from one of the entries in my > directory: > > pwdChangedTime: 20110502160329Z > sambaPwdLastSet: 1304352209 > > Obviously, pwdChangedTime specifies the timestamp: > > Mon May 2 16:03:29 EDT 2011 > > On the other hand, sambaPwdLastSet specifies the timestamp as being an hour > later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 > sec'): > > Mon May 2 17:03:29 EDT 2011 > > Right now we're in DST on the east coast, which is GMT -0400. This would mean > that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly > calculating results using GMT -0500. The sambaPwdLastSet value is not calculated at all, it is exactly what the OS system clock returns, and the OS system clock is in UTC so DST is irrelevant. Probably your machine's timezone is misconfigured; notice that pwdChangedTime is also in UTC so 20110502160329Z cannot be "May 2 16:03:29 EDT". Closing this ITS. -- -- 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#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com 04 May '11

04 May '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server 10.04 (Lucid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet attribute, populating it with a value that does not take DST into account. As an example, consider the following attributes from one of the entries in my directory: pwdChangedTime: 20110502160329Z sambaPwdLastSet: 1304352209 Obviously, pwdChangedTime specifies the timestamp: Mon May 2 16:03:29 EDT 2011 On the other hand, sambaPwdLastSet specifies the timestamp as being an hour later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 sec'): Mon May 2 17:03:29 EDT 2011 Right now we're in DST on the east coast, which is GMT -0400. This would mean that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly calculating results using GMT -0500.

1 0

(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de 04 May '11

04 May '11

Full_Name: Sascha Kuehndel Version: 2.4.25 OS: HP-UX 11.31 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.166.104.102) Hi, i tested the delta-sync in a multi-master (2 master) architecture. In a split-brain szenario the sync produced an undefinded state. Some times the data wasn't synchronized (both master hold there data unchanged), sometimes the data was fliped (master1 take data from master2, and master2 from master1). A defined and synchronized state must reached after the end of the split-brain. Senario: 1. master1 and master2 runs in sync 2. shutdown of master2 3. data change on master1 4. shutdown of master1 5. start of master2 6. data change on master2 (the same attribute on the same object, other value) > now the masters are out of sync in the same field 7. restart of master1 8. the sync process is running 9. take a look on the change field.. there are different regards Sascha Kuehndel PS - Nice to have: The posibility to define the action in thouch an situation - master1 or master2... wins - the newest win - or no change and the posibility to write a log-entry about it (with the exact dn,the attribute and the values before the synchronization)

1 0

Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com 03 May '11

03 May '11

--On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> Nothing in the OpenLDAP code issues a truncate operation of any sort. > > There are several fopen(filename, "w") calls, which truncate the file. > Maybe the error confuses slapd so it takes a detour into one of them. > > Quanah, can you provide a full slapd.conf and command line which causes > this? Not that I have a Windows box to test it on, but still... The command line was just slapd.exe -d -1 -f slapd.conf The slapd.conf itself is fairly small. The line that wrapped was the include for inetOrgPerson. Everything obviously stopped when it hit the wrapped include. ucdata-path "/opt/zimbra/openldap/ucdata" include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/schema/zimbra.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" modulepath /opt/zimbra/openldap/openldap moduleload back_bdb-2-4-2.dll moduleload back_monitor-2-4-2.dll access to dn.subtree="" by dn.children="cn=admins,cn=zimbra" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootpw {SSHA}8+r0nkcErptqasSrFPcT0k81NFrbTcAS database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra" read database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/opt/zimbra/data/ldap/hdb/db" index objectClass eq index uid pres,eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=objectclass,zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs
by daniel＠pluta.biz 03 May '11

03 May '11

In case authcIDs do not need to be normalized, this seems to be a better place to disable normalization: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110502.patch Now authzIDs of the form "u:xxxx" are also affected.

1 0

(ITS#6925) [PATCH] Use inet_ntop for server when available
by delphij＠gmail.com 02 May '11

02 May '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD/amd64 9.0-CURRENT URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) slapd uses inet_ntoa in several places and some of them does not use inet_ntop when it's available. The inet_ntoa is not thread-safe on FreeBSD and thus could cause denial of service if it loses the race, when an IP based ACL is in effect. diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c index aea3b39..65ce576 100644 --- a/servers/slapd/connection.c +++ b/servers/slapd/connection.c @@ -1500,12 +1500,21 @@ connection_input( Connection *conn , conn_readinfo *cri ) #ifdef LDAP_CONNECTIONLESS if ( conn->c_is_udp ) { char peername[sizeof("IP=255.255.255.255:65336")]; + const char *peeraddr = NULL; len = ber_int_sb_read(conn->c_sb, &peeraddr, sizeof(struct sockaddr)); if (len != sizeof(struct sockaddr)) return 1; +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &peeraddr.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ + peeraddr = inet_ntoa( peeraddr.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", - inet_ntoa( peeraddr.sa_in_addr.sin_addr ), + peeraddr, (unsigned) ntohs( peeraddr.sa_in_addr.sin_port ) ); Statslog( LDAP_DEBUG_STATS, "conn=%lu UDP request from %s (%s) accepted.\n", diff --git a/servers/slapd/daemon.c b/servers/slapd/daemon.c index 8e8a69d..ccfa2ee 100644 --- a/servers/slapd/daemon.c +++ b/servers/slapd/daemon.c @@ -1971,8 +1971,16 @@ slap_listener( # ifdef LDAP_PF_INET6 case AF_INET6: if ( IN6_IS_ADDR_V4MAPPED(&from.sa_in6_addr.sin6_addr) ) { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, + ((struct in_addr *)&from.sa_in6_addr.sin6_addr.s6_addr[12]), + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( *((struct in_addr *) &from.sa_in6_addr.sin6_addr.s6_addr[12]) ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in6_addr.sin6_port ) ); @@ -1989,12 +1997,19 @@ slap_listener( break; # endif /* LDAP_PF_INET6 */ - case AF_INET: + case AF_INET: { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &from.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( from.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in_addr.sin_port ) ); - break; + } break; default: slapd_close(sfd);

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2011