Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com
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/
11 years, 9 months
(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com
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}
11 years, 9 months
Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com
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/
11 years, 9 months
(ITS#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com
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.
11 years, 9 months
(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de
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)
11 years, 9 months
Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com
--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
11 years, 9 months
(ITS#6925) [PATCH] Use inet_ntop for server when available
by delphij＠gmail.com
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);
11 years, 9 months
