Full_Name: Igor Brezac Version: 2.1.25 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.170.142.3) LDAP_CONTROL_PROXY_AUTHZ does not set mech which may create problems for some sasl configurations. Here is my example. sasl-regexp uid=(.*),cn=(.*),cn=(.*),cn=auth associateddomain=$2+cn=$1,ou=people,o=pb sasl-regexp uid=(.*),cn=(.*),cn=auth cn=$1,ou=people,ou=admin,o=pb If the first sasl-regexp is not present, the second one would fail as well. ==>slap_sasl2dn: converting SASL name uid=igor,cn=ipass.net,cn=auth to a DN slap_sasl_regexp: converting SASL name uid=igor,cn=ipass.net,cn=auth slap_sasl_regexp: converted SASL name to cn=igor,ou=people,ou=admin,o=pb I expected something like (from ldapwhoami cmd tool): <<< dnNormalize: <uid=pino,cn=ipass.net,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=igor,cn=ipass.net,cn=digest-md5,cn=auth to a DN slap_sasl_regexp: converting SASL name uid=igor,cn=ipass.net,cn=digest-md5,cn=auth slap_sasl_regexp: converted SASL name to associateddomain=ipass.net+cn=igor,ou=people,o=pb
> Full_Name: Igor Brezac > Version: 2.1.25 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.170.142.3) > > > LDAP_CONTROL_PROXY_AUTHZ does not set mech which may create problems for > some sasl configurations. Here is my example. > > sasl-regexp uid=(.*),cn=(.*),cn=(.*),cn=auth > associateddomain=$2+cn=$1,ou=people,o=pb > > sasl-regexp uid=(.*),cn=(.*),cn=auth > cn=$1,ou=people,ou=admin,o=pb This is incorrect; try sasl-regexp uid=([^,]+),cn=(.*),cn=auth cn=$1,ou=people,ou=admin,o=pb because regexp in case of ambiguities chooses the largest matches. p. > > If the first sasl-regexp is not present, the second one would fail as > well. > > ==>slap_sasl2dn: converting SASL name uid=igor,cn=ipass.net,cn=auth to a > DN slap_sasl_regexp: converting SASL name uid=igor,cn=ipass.net,cn=auth > slap_sasl_regexp: converted SASL name to cn=igor,ou=people,ou=admin,o=pb > > I expected something like (from ldapwhoami cmd tool): > > <<< dnNormalize: <uid=pino,cn=ipass.net,cn=digest-md5,cn=auth> > ==>slap_sasl2dn: converting SASL name > uid=igor,cn=ipass.net,cn=digest-md5,cn=auth to a DN > slap_sasl_regexp: converting SASL name > uid=igor,cn=ipass.net,cn=digest-md5,cn=auth > slap_sasl_regexp: converted SASL name to > associateddomain=ipass.net+cn=igor,ou=people,o=pb -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
On Thu, 11 Dec 2003, Pierangelo Masarati wrote: > > > Full_Name: Igor Brezac > > Version: 2.1.25 > > OS: Solaris 9 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (209.170.142.3) > > > > > > LDAP_CONTROL_PROXY_AUTHZ does not set mech which may create problems for > > some sasl configurations. Here is my example. > > > > sasl-regexp uid=(.*),cn=(.*),cn=(.*),cn=auth > > associateddomain=$2+cn=$1,ou=people,o=pb > > > > sasl-regexp uid=(.*),cn=(.*),cn=auth > > cn=$1,ou=people,ou=admin,o=pb > > This is incorrect; try > > sasl-regexp uid=([^,]+),cn=(.*),cn=auth > cn=$1,ou=people,ou=admin,o=pb > > because regexp in case of ambiguities chooses > the largest matches. > I tried, but it does not make any difference. > > > > > If the first sasl-regexp is not present, the second one would fail as > > well. > > > > ==>slap_sasl2dn: converting SASL name uid=igor,cn=ipass.net,cn=auth to a I expected this to be uid=igor,cn=ipass.net,cn=<mech>,cn=auth -Igor > > DN slap_sasl_regexp: converting SASL name uid=igor,cn=ipass.net,cn=auth > > slap_sasl_regexp: converted SASL name to cn=igor,ou=people,ou=admin,o=pb > > > > I expected something like (from ldapwhoami cmd tool): > > > > <<< dnNormalize: <uid=pino,cn=ipass.net,cn=digest-md5,cn=auth> > > ==>slap_sasl2dn: converting SASL name > > uid=igor,cn=ipass.net,cn=digest-md5,cn=auth to a DN > > slap_sasl_regexp: converting SASL name > > uid=igor,cn=ipass.net,cn=digest-md5,cn=auth > > slap_sasl_regexp: converted SASL name to > > associateddomain=ipass.net+cn=igor,ou=people,o=pb > > > -- Igor
> LDAP_CONTROL_PROXY_AUTHZ does not set mech which may create problems for some > sasl configurations. Here is my example. Can you elaborate on the operation you're doing? What's the setup, what's the client, what proxyAuthz you're submitting, and so? Apparently, the proxyAuthz control transforms the string that is input into a DN without any realm (which is not dfined as a separate field in the procyAuthz request, so it needs to be provided together with the userid; e.g.: u:uid=<username>@<realm> Can you provide more detailed logging? Also, read sasl.c:slap_sasl2dn() sources, and how it's invoked in controls.c:parseProxyAuthz() to understand how the user ID for the proxyAuthz control should be crafted. p.
changed notes changed state Open to Feedback
On Sat, 13 Dec 2003, Wrangle Macerate wrote: > > LAP_CONTROL_PROXY_AUTHOR does not set match which may create problems for some > > Sask configurations. Here is my example. > > Can you elaborate on the operation you're doing? What's the setup, > what's the client, what paroxysms you're submitting, and so? I am using Howard's ldap based sasl auxpop plugin ($opened-SEC/countering/lapses/laded.c) > > Apparently, the Procyon's control transforms the string that is > input into a DNA without any realm (which is not dinged as a separate > field in the procyAuthz request, so it needs to be provided together > with the userid; e.g.: > > u:uid=<username>@<realm> It is, but in the form of u:<username>@<realm>. Look in ldapdb.c:ldapdb_connect(). > > Can you provide more detailed logging? Also, read sasl.c:slap_sasl2dn() > sources, and how it's invoked in controls.c:parseProxyAuthz() > to understand how the user ID for the proxyAuthz control should > be crafted. The parsing of authzid works as expected, however slap_sasl_getdn() generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather than uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes problems with existing sasl-regexps which expect <mech> in place of <realm> as described in slapd.conf. I hope this explains better. It seems to me the internal sasl operation does not require mech, therefore slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. -- Igor
> > On Sat, 13 Dec 2003, Wrangle Macerate wrote: > >> > LAP_CONTROL_PROXY_AUTHOR does not set match which may create >> problems for some Sask configurations. Here is my example. >> >> Can you elaborate on the operation you're doing? What's the setup, >> what's the client, what paroxysms you're submitting, and so? > > I am using Howard's ldap based sasl auxpop plugin > ($opened-SEC/countering/lapses/laded.c) > > >> >> Apparently, the Procyon's control transforms the string that is >> input into a DNA without any realm (which is not dinged as a separate >> field in the procyAuthz request, so it needs to be provided together >> with the userid; e.g.: >> >> u:uid=<username>@<realm> > > It is, but in the form of u:<username>@<realm>. Look in > ldapdb.c:ldapdb_connect(). Sorry, that's exactly what I meant. > >> >> Can you provide more detailed logging? Also, read >> sasl.c:slap_sasl2dn() sources, and how it's invoked in >> controls.c:parseProxyAuthz() >> to understand how the user ID for the proxyAuthz control should >> be crafted. > > The parsing of authzid works as expected, however slap_sasl_getdn() > generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather than > uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes problems with > existing sasl-regexps which expect <mech> in place of <realm> as > described in slapd.conf. I hope this explains better. It seems to me > the internal sasl operation does not require mech Now I see. There is no chance it sets the mech because there isn't any. We are looking at a workaround that is general enough to take care of this case as well. If you follow the thread on the -devel list, we're discussing the possibility to put a fake mechanism ("authz") to mark that the identity results from a proxyauthz operation. > , therefore > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. Ando. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
> The parsing of authzid works as expected, however slap_sasl_getdn() > generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather than > uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes problems with > existing sasl-regexps which expect <mech> in place of <realm> as > described in slapd.conf. I hope this explains better. It seems to me > the internal sasl operation does not require mech, therefore > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. I need to correct myself. The code should use the same mech that was used to authenticate the authc id; apparently, a simple bind took place instead of a sasl bind. I wonder i this is the correct behaviour, though. In fact, I'm not sure it is correct that the authz id inherits the same mec of the authc id, because another operation (the proxyAuthz) intercurred. As such, we could add the "authz" mechanism to the sasl id, at least if none is present. In any case, you shuld check whether a sasl bind takes place. If it doesn't, then there is no bug. If it does, then I'm not sure yet there's a bug, because I'm not sure it's correct that the authz id tkes the same mech that as used for the authc op. Ando. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > > The parsing of authzid works as expected, however slap_sasl_getdn() > > generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather than > > uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes problems with > > existing sasl-regexps which expect <mech> in place of <realm> as > > described in slapd.conf. I hope this explains better. It seems to me > > the internal sasl operation does not require mech, therefore > > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. > > I need to correct myself. The code should use the same mech > that was used to authenticate the authc id; apparently, a simple > bind took place instead of a sasl bind. I wonder i this is > the correct behaviour, though. In fact, I'm not sure it is > correct that the authz id inherits the same mec of the authc id, > because another operation (the proxyAuthz) intercurred. > As such, we could add the "authz" mechanism to the sasl id, > at least if none is present. > > In any case, you shuld check whether a sasl bind takes place. > It does use sasl bind. In my case I used digest-md5. -- Igor
> > On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > >> > The parsing of authzid works as expected, however slap_sasl_getdn() >> generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather >> than uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes >> problems with existing sasl-regexps which expect <mech> in place of >> <realm> as described in slapd.conf. I hope this explains better. >> It seems to me the internal sasl operation does not require mech, >> therefore >> > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. >> >> I need to correct myself. The code should use the same mech >> that was used to authenticate the authc id; apparently, a simple bind >> took place instead of a sasl bind. I wonder i this is >> the correct behaviour, though. In fact, I'm not sure it is >> correct that the authz id inherits the same mec of the authc id, >> because another operation (the proxyAuthz) intercurred. >> As such, we could add the "authz" mechanism to the sasl id, >> at least if none is present. >> >> In any case, you shuld check whether a sasl bind takes place. >> > > It does use sasl bind. In my case I used digest-md5. You're right. There actually is a bug; Howard pointed out that slap_sasl_getdn() looks for the method in a member that is correctly set only during bind. Try HEAD code right now. I also need to chck whether the realm is still handled properly. Ando. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > > > > > On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > > > >> > The parsing of authzid works as expected, however slap_sasl_getdn() > >> generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather > >> than uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes > >> problems with existing sasl-regexps which expect <mech> in place of > >> <realm> as described in slapd.conf. I hope this explains better. > >> It seems to me the internal sasl operation does not require mech, > >> therefore > >> > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. > >> > >> I need to correct myself. The code should use the same mech > >> that was used to authenticate the authc id; apparently, a simple bind > >> took place instead of a sasl bind. I wonder i this is > >> the correct behaviour, though. In fact, I'm not sure it is > >> correct that the authz id inherits the same mec of the authc id, > >> because another operation (the proxyAuthz) intercurred. > >> As such, we could add the "authz" mechanism to the sasl id, > >> at least if none is present. > >> > >> In any case, you shuld check whether a sasl bind takes place. > >> > > > > It does use sasl bind. In my case I used digest-md5. > > You're right. There actually is a bug; Howard pointed out that > slap_sasl_getdn() looks for the method in a member that is > correctly set only during bind. Try HEAD code right now. > I also need to chck whether the realm is still handled properly. I'll try later in the evening. I'll let you know what I find. -- Igor
changed notes changed state Feedback to Test moved from Incoming to Software Bugs
On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > > > > > On Sat, 13 Dec 2003, Pierangelo Masarati wrote: > > > >> > The parsing of authzid works as expected, however slap_sasl_getdn() > >> generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather > >> than uid=<userid>,cn=<realm>,cn=<mech>,cn=auth. This causes > >> problems with existing sasl-regexps which expect <mech> in place of > >> <realm> as described in slapd.conf. I hope this explains better. > >> It seems to me the internal sasl operation does not require mech, > >> therefore > >> > slap_sasl_getdn() cannot set cn=<mech> properly in the sasl DN. > >> > >> I need to correct myself. The code should use the same mech > >> that was used to authenticate the authc id; apparently, a simple bind > >> took place instead of a sasl bind. I wonder i this is > >> the correct behaviour, though. In fact, I'm not sure it is > >> correct that the authz id inherits the same mec of the authc id, > >> because another operation (the proxyAuthz) intercurred. > >> As such, we could add the "authz" mechanism to the sasl id, > >> at least if none is present. > >> > >> In any case, you shuld check whether a sasl bind takes place. > >> > > > > It does use sasl bind. In my case I used digest-md5. > > You're right. There actually is a bug; Howard pointed out that > slap_sasl_getdn() looks for the method in a member that is > correctly set only during bind. Try HEAD code right now. > I also need to chck whether the realm is still handled properly. It works with changes. I needed to change sasl-regex because uid now contains full username (userid@domain) and the format of saslAuthzTo changed. It appears that cn=realm is not generated now even though I passed it on the command line. ldapwhoami -U root -R realm -X u=igor@ipass.net -Y digest-md5 -- Igor
> I needed to change sasl-regex because uid now contains full username > (userid@domain) and the format of saslAuthzTo changed. It appears that > cn=realm is not generated now even though I passed it on the command > line. ldapwhoami -U root -R realm -X u=igor@ipass.net -Y digest-md5 Yes, the current code does not allow a realm unless you also specify a mechanism, but mechanisms are forbidden in proxyAuthz IDs (sort of a catch 22); I'll see what I can do. The point is that we found out we cannot rely on <user>@<realm> syntax because '@' is a legal char both in realms and in usernames, and many systems rely on this by using email addresses as userids. So we came out with this user specification: u[.<mech>[/<realm>]]:<username> which allows to specify everything without ambiguity. Maybe we can alleviate it to u[.<mech>][/<realm>]:<username> (note the square brackets ...), but I need to check security and generality implications, so that you can use ldap* -e '!authzid=u/ipass.net:igor' for your proxyAuthz control, or ldap* -e '!authzid=u.AUTHZ/ipass.net:igor' where the fake AUTHZ mechanism is accepted. I favour this latter solution, and I just checked in the related changes. Also, note that now the <mech> will always be present in the SASL name; if one uses simple bind, a fake mechanism "cn=SIMPLE" will be used. p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
On Mon, 15 Dec 2003, Pierangelo Masarati wrote: > > > I needed to change sasl-regex because uid now contains full username > > (userid@domain) and the format of saslAuthzTo changed. It appears that > > cn=realm is not generated now even though I passed it on the command > > line. ldapwhoami -U root -R realm -X u=igor@ipass.net -Y digest-md5 > > Yes, the current code does not allow a realm unless you also > specify a mechanism, but mechanisms are forbidden in > proxyAuthz IDs (sort of a catch 22); I'll see what I can do. > > The point is that we found out we cannot rely on <user>@<realm> > syntax because '@' is a legal char both in realms and in usernames, > and many systems rely on this by using email addresses as userids. > So we came out with this user specification: I agree with this. I really do not use realms, but I will need it in the future. I hope other apps (cyrus-imap, sendmail, etc) will follow this standard. Unfortunately, a lot of people assume that realm and domain are the same. > > u[.<mech>[/<realm>]]:<username> > > which allows to specify everything without ambiguity. > > Maybe we can alleviate it to > > u[.<mech>][/<realm>]:<username> > > (note the square brackets ...), but I need to check security > and generality implications, so that you can use > > ldap* -e '!authzid=u/ipass.net:igor' > > for your proxyAuthz control, or > > ldap* -e '!authzid=u.AUTHZ/ipass.net:igor' Is -R going to be eliminated? > where the fake AUTHZ mechanism is accepted. I favour this > latter solution, and I just checked in the related changes. > > Also, note that now the <mech> will always be present > in the SASL name; if one uses simple bind, a fake mechanism > "cn=SIMPLE" will be used. I noticed this. ;) I assume that realm is going to be ignored for mechs that do not use it? How is this going to work with GSSAPI? -- Igor
> > On Mon, 15 Dec 2003, Pierangelo Masarati wrote: > >> >> > I needed to change sasl-regex because uid now contains full username >> (userid@domain) and the format of saslAuthzTo changed. It appears >> that cn=realm is not generated now even though I passed it on the >> command line. ldapwhoami -U root -R realm -X u=igor@ipass.net -Y >> digest-md5 >> >> Yes, the current code does not allow a realm unless you also >> specify a mechanism, but mechanisms are forbidden in >> proxyAuthz IDs (sort of a catch 22); I'll see what I can do. >> >> The point is that we found out we cannot rely on <user>@<realm> >> syntax because '@' is a legal char both in realms and in usernames, >> and many systems rely on this by using email addresses as userids. So >> we came out with this user specification: > > I agree with this. I really do not use realms, but I will need it in > the future. I hope other apps (cyrus-imap, sendmail, etc) will follow > this standard. Unfortunately, a lot of people assume that realm and > domain are the same. ... > >> >> u[.<mech>[/<realm>]]:<username> >> >> which allows to specify everything without ambiguity. >> >> Maybe we can alleviate it to >> >> u[.<mech>][/<realm>]:<username> >> >> (note the square brackets ...), but I need to check security >> and generality implications, so that you can use >> >> ldap* -e '!authzid=u/ipass.net:igor' >> >> for your proxyAuthz control, or >> >> ldap* -e '!authzid=u.AUTHZ/ipass.net:igor' > > Is -R going to be eliminated? No, this is the realm used for SASL authc (by those mechs that require it). If they set the realm in the SASL authc, that one is used. The realm you can supply in the proxyauthz control is used only if it is not st by SASL. In other words, the proxyAuthz'd ID inherits SASL realm and mechnism from the authc ID; if the latter does not set any, you can explicitly set the realm by the mechanism illustrated above. However you cannot override the mech, which is set to SIMPLE if no SASL auth took place. This is for security reasons. > >> where the fake AUTHZ mechanism is accepted. I favour this >> latter solution, and I just checked in the related changes. >> >> Also, note that now the <mech> will always be present >> in the SASL name; if one uses simple bind, a fake mechanism >> "cn=SIMPLE" will be used. > > I noticed this. ;) I assume that realm is going to be ignored for > mechs that do not use it? yes. > > How is this going to work with GSSAPI? GSSAPI should hve the realm and the mech set appropriately by the SASL authc, AFAIK. p. -- Pierangelo Masarati mailto:pierangelo.masarati@sys-net.it
Thanks. Is this patch going to be backported to 2.1.x? -Igor On Mon, 15 Dec 2003, Pierangelo Masarati wrote: > > > > > On Mon, 15 Dec 2003, Pierangelo Masarati wrote: > > > >> > >> > I needed to change sasl-regex because uid now contains full username > >> (userid@domain) and the format of saslAuthzTo changed. It appears > >> that cn=realm is not generated now even though I passed it on the > >> command line. ldapwhoami -U root -R realm -X u=igor@ipass.net -Y > >> digest-md5 > >> > >> Yes, the current code does not allow a realm unless you also > >> specify a mechanism, but mechanisms are forbidden in > >> proxyAuthz IDs (sort of a catch 22); I'll see what I can do. > >> > >> The point is that we found out we cannot rely on <user>@<realm> > >> syntax because '@' is a legal char both in realms and in usernames, > >> and many systems rely on this by using email addresses as userids. So > >> we came out with this user specification: > > > > I agree with this. I really do not use realms, but I will need it in > > the future. I hope other apps (cyrus-imap, sendmail, etc) will follow > > this standard. Unfortunately, a lot of people assume that realm and > > domain are the same. > > ... > > > > >> > >> u[.<mech>[/<realm>]]:<username> > >> > >> which allows to specify everything without ambiguity. > >> > >> Maybe we can alleviate it to > >> > >> u[.<mech>][/<realm>]:<username> > >> > >> (note the square brackets ...), but I need to check security > >> and generality implications, so that you can use > >> > >> ldap* -e '!authzid=u/ipass.net:igor' > >> > >> for your proxyAuthz control, or > >> > >> ldap* -e '!authzid=u.AUTHZ/ipass.net:igor' > > > > Is -R going to be eliminated? > > No, this is the realm used for SASL authc (by those mechs > that require it). If they set the realm in the SASL > authc, that one is used. The realm you can supply in the > proxyauthz control is used only if it is not st by SASL. > > In other words, the proxyAuthz'd ID inherits SASL realm > and mechnism from the authc ID; if the latter does not set > any, you can explicitly set the realm by the mechanism > illustrated above. However you cannot override the mech, > which is set to SIMPLE if no SASL auth took place. This > is for security reasons. > > > > >> where the fake AUTHZ mechanism is accepted. I favour this > >> latter solution, and I just checked in the related changes. > >> > >> Also, note that now the <mech> will always be present > >> in the SASL name; if one uses simple bind, a fake mechanism > >> "cn=SIMPLE" will be used. > > > > I noticed this. ;) I assume that realm is going to be ignored for > > mechs that do not use it? > > yes. > > > > > How is this going to work with GSSAPI? > > GSSAPI should hve the realm and the mech set appropriately > by the SASL authc, AFAIK. > > p. > > -- Igor
changed notes changed state Test to Suspended
changed notes
changed notes changed state Suspended to Release
I've just backported this patch to RE21. Assuming there are no issues with the patch, it should be in 2.1.26. Please test RE21...
>>>>> Starting test007-replication ... running defines.sh Cleaning up in ./test-db... Cleaning up in ./test-repl... Starting master slapd on TCP/IP port 9009... Starting slave slapd on TCP/IP port 9010... Using ldapsearch to check that master slapd is running... Waiting 5 seconds for slapd to start... Using ldapsearch to check that slave slapd is running... Starting slurpd... Using ldapadd to populate the master directory... 23865 Abort ldapadd failed (81)! ./scripts/test007-replication: kill: no such process >>>>> ./scripts/test007-replication failed (exit 81) make[1]: *** [test-bdb] Error 81 make[1]: Leaving directory `/var/src/openldap-2.1.26/tests' make: *** [test] Error 2 tail master.log bdb_idl_insert_key: 2 %o=university of michigan,c=us <= bdb_dn2id_add: 0 => entry_encode(0x00000002): ou=People,o=University of Michigan,c=US => index_entry_add( 2, "ou=People,o=University of Michigan,c=US" ) => key_change(ADD,2) bdb_idl_insert_key: 2 [9bee355f] <= key_change 0 => key_change(ADD,2) bdb_idl_insert_key: 2 [0096defd] <= key_change 0 <= index_entry_add( 2, "ou=People,o=University of Michigan,c=US" ) success conn=2 op=1 RESULT tag=105 err=0 text= ch_malloc of 1424779042 bytes failed ch_malloc.c:38: failed assertion `0' On Wed, 21 Jan 2004, Howard Chu wrote: > I've just backported this patch to RE21. Assuming there are no issues with the > patch, it should be in 2.1.26. Please test RE21... > -- Igor
All the tests run cleanly for me. Try to get a gdb backtrace of the crash. Also probably need to know your configure options, platform, etc. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of igor@ipass.net > Sent: Wednesday, January 21, 2004 9:24 AM > To: openldap-its@OpenLDAP.org > Subject: Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871) > > > > >>>>> Starting test007-replication ... > running defines.sh > Cleaning up in ./test-db... > Cleaning up in ./test-repl... > Starting master slapd on TCP/IP port 9009... > Starting slave slapd on TCP/IP port 9010... > Using ldapsearch to check that master slapd is running... > Waiting 5 seconds for slapd to start... > Using ldapsearch to check that slave slapd is running... > Starting slurpd... > Using ldapadd to populate the master directory... > 23865 Abort > ldapadd failed (81)! > ./scripts/test007-replication: kill: no such process > >>>>> ./scripts/test007-replication failed (exit 81) > make[1]: *** [test-bdb] Error 81 > make[1]: Leaving directory `/var/src/openldap-2.1.26/tests' > make: *** [test] Error 2 > > tail master.log > bdb_idl_insert_key: 2 %o=university of michigan,c=us > <= bdb_dn2id_add: 0 > => entry_encode(0x00000002): ou=People,o=University of Michigan,c=US > => index_entry_add( 2, "ou=People,o=University of Michigan,c=US" ) > => key_change(ADD,2) > bdb_idl_insert_key: 2 [9bee355f] > <= key_change 0 > => key_change(ADD,2) > bdb_idl_insert_key: 2 [0096defd] > <= key_change 0 > <= index_entry_add( 2, "ou=People,o=University of > Michigan,c=US" ) success > conn=2 op=1 RESULT tag=105 err=0 text= > ch_malloc of 1424779042 bytes failed > ch_malloc.c:38: failed assertion `0' > > On Wed, 21 Jan 2004, Howard Chu wrote: > > > I've just backported this patch to RE21. Assuming there are > no issues with the > > patch, it should be in 2.1.26. Please test RE21... > > > > -- > Igor > > >
(gdb) bt #0 0xfee1e694 in _lwp_kill () from /usr/lib/libc.so.1 #1 0xfedccfe0 in raise () from /usr/lib/libc.so.1 #2 0xfedb5c80 in abort () from /usr/lib/libc.so.1 #3 __eprintf (string=0x923c8 "%s:%u: failed assertion `%s'\n", expression=0x923e8 "ch_malloc.c", line=38, filename=0x923f8 "0") at ../../gcc/libgcc2.c:-1 #4 0x000369f4 in ch_malloc (size=1424779042) at ch_malloc.c:38 #5 0x0004139c in print_vals (fp=0xc74a0, type=0xfee41fd8, bv=0xfee41fc8) at repl.c:440 #6 0x00040fd0 in replog1 (ri=0x0, op=0x1644b0, change=0xfee41fa0, fp=0xc74a0, dn=0x1647dc, now=1074720817) at repl.c:402 #7 0x000408a8 in replog (be=0x10df78, op=0x1644b0, dn=0x1647dc, ndn=0x1647e4, change=0x1647d8) at repl.c:180 #8 0x00026174 in do_add (conn=0x119f28, op=0x1644b0) at add.c:313 #9 0x00020798 in connection_operation (ctx=0x1173f8, arg_v=0x1644b0) at connection.c:918 #10 0xff34bbf4 in ldap_int_thread_pool_wrapper (xpool=0xc82a0) at tpool.c:432 Hope this helps. -Igor On Wed, 21 Jan 2004, Howard Chu wrote: > All the tests run cleanly for me. Try to get a gdb backtrace of the crash. > Also probably need to know your configure options, platform, etc. > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support > > > -----Original Message----- > > From: owner-openldap-bugs@OpenLDAP.org > > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of igor@ipass.net > > Sent: Wednesday, January 21, 2004 9:24 AM > > To: openldap-its@OpenLDAP.org > > Subject: Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871) > > > > > > > > >>>>> Starting test007-replication ... > > running defines.sh > > Cleaning up in ./test-db... > > Cleaning up in ./test-repl... > > Starting master slapd on TCP/IP port 9009... > > Starting slave slapd on TCP/IP port 9010... > > Using ldapsearch to check that master slapd is running... > > Waiting 5 seconds for slapd to start... > > Using ldapsearch to check that slave slapd is running... > > Starting slurpd... > > Using ldapadd to populate the master directory... > > 23865 Abort > > ldapadd failed (81)! > > ./scripts/test007-replication: kill: no such process > > >>>>> ./scripts/test007-replication failed (exit 81) > > make[1]: *** [test-bdb] Error 81 > > make[1]: Leaving directory `/var/src/openldap-2.1.26/tests' > > make: *** [test] Error 2 > > > > tail master.log > > bdb_idl_insert_key: 2 %o=university of michigan,c=us > > <= bdb_dn2id_add: 0 > > => entry_encode(0x00000002): ou=People,o=University of Michigan,c=US > > => index_entry_add( 2, "ou=People,o=University of Michigan,c=US" ) > > => key_change(ADD,2) > > bdb_idl_insert_key: 2 [9bee355f] > > <= key_change 0 > > => key_change(ADD,2) > > bdb_idl_insert_key: 2 [0096defd] > > <= key_change 0 > > <= index_entry_add( 2, "ou=People,o=University of > > Michigan,c=US" ) success > > conn=2 op=1 RESULT tag=105 err=0 text= > > ch_malloc of 1424779042 bytes failed > > ch_malloc.c:38: failed assertion `0' > > > > On Wed, 21 Jan 2004, Howard Chu wrote: > > > > > I've just backported this patch to RE21. Assuming there are > > no issues with the > > > patch, it should be in 2.1.26. Please test RE21... > > > > > > > -- > > Igor > > > > > > > > -- Igor
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
mech was not propagated, fixed in HEAD,2.2.4,re21