- openldap-bugs - openldap.org

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 12 Nov '06

12 Nov '06

Pierangelo Masarati wrote: > Howard Chu wrote: >> OK. And we have usually used DEBUG_ANY for fatal messages of this >> type. The point I'm making now is that config errors are no longer >> always fatal; it depends on whether we're starting up or already running. > But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools > now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages > would let them always pop up with tools __and__ run-time; run-time it > shouldn't be a big deal, it's just another informative message in the > logs; with the tools it should make the difference. I have no > preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by > default in tools, or OR config messages with LDAP_DEBUG_NONE. OK, that makes sense. Perhaps we should define LDAP_DEBUG_ERROR (or _FATAL) as an alias of LDAP_DEBUG_NONE. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 12 Nov '06

12 Nov '06

Howard Chu wrote: > OK. And we have usually used DEBUG_ANY for fatal messages of this > type. The point I'm making now is that config errors are no longer > always fatal; it depends on whether we're starting up or already running. But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages would let them always pop up with tools __and__ run-time; run-time it shouldn't be a big deal, it's just another informative message in the logs; with the tools it should make the difference. I have no preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by default in tools, or OR config messages with LDAP_DEBUG_NONE. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 12 Nov '06

12 Nov '06

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another possibility would be to always enable LDAP_DEBUG_CONFIG for the >> tools. The only reason I suggest this is because I would prefer that >> runtime configuration errors are only logged when specifically >> requested, not at DEBUG_ANY. Since the error messages are already >> returnes to the client in the protocol, it's not always necessary to log >> them separately. >> > The point is that I'd like to separate informative messages about > configuration (LDAP_DEBUG_CONFIG) from __the__ message that described > why slaptest failed (or slapd refuses to start). Right now, either you > get all (which is annoying) or none (which is frustrating). Apparently, > unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and > OR it to all messages followed by "return ARG_BAD_CONF;", we need > another LDAP_DEBUG_*. OK. And we have usually used DEBUG_ANY for fatal messages of this type. The point I'm making now is that config errors are no longer always fatal; it depends on whether we're starting up or already running. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 12 Nov '06

12 Nov '06

hyc(a)symas.com wrote: > Another possibility would be to always enable LDAP_DEBUG_CONFIG for the > tools. The only reason I suggest this is because I would prefer that > runtime configuration errors are only logged when specifically > requested, not at DEBUG_ANY. Since the error messages are already > returnes to the client in the protocol, it's not always necessary to log > them separately. > The point is that I'd like to separate informative messages about configuration (LDAP_DEBUG_CONFIG) from __the__ message that described why slaptest failed (or slapd refuses to start). Right now, either you get all (which is annoying) or none (which is frustrating). Apparently, unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and OR it to all messages followed by "return ARG_BAD_CONF;", we need another LDAP_DEBUG_*. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> It seems that slapd stops without configuration error message if unknown >> attribute types are set for parameter unique_attributes (slapo-unique). It would >> be nice if a descriptive message is displayed (like in other cases). >> > I think this occurs if debug is set to "config" or "-1". However, it > would be more appropriate to log configuration errors that result in > failures at "any", so that whatever logging is set they show up. For > this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG > should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that > they show up when caught by tools with default logging (e.g. > slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. > I'd vote for the latter. Another possibility would be to always enable LDAP_DEBUG_CONFIG for the tools. The only reason I suggest this is because I would prefer that runtime configuration errors are only logged when specifically requested, not at DEBUG_ANY. Since the error messages are already returnes to the client in the protocol, it's not always necessary to log them separately. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

--On Saturday, November 11, 2006 9:10 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.28 >> OS: Linux 2.6 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.155.86) >> >> >> When building OpenLDAP 2.3.28, I found that libslapi is full of undefined >> symbols. Is it not being linked correctly? >> > Do you actually have a slapi plugin that isn't working? There's no > evidence of a bug here. Most dynamic libraries that depend on other > objects are full of undefined symbols. Nope, I don't use slapi at all, other than to enable it to disable the broken acl cacheing in 2.3. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4745) libslapi undefined symbols
by hyc＠symas.com 11 Nov '06

11 Nov '06

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.28 > OS: Linux 2.6 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.66.155.86) > > > When building OpenLDAP 2.3.28, I found that libslapi is full of undefined > symbols. Is it not being linked correctly? > Do you actually have a slapi plugin that isn't working? There's no evidence of a bug here. Most dynamic libraries that depend on other objects are full of undefined symbols. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When building OpenLDAP 2.3.28, I found that libslapi is full of undefined symbols. Is it not being linked correctly? ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd libslapi.so libc.so.6 => /lib/libc.so.6 (0x00002b58357d6000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ldap-uat00:/usr/local/stow/openldap-2.3.28.9-gcc411/lib> ldd -r -d libslapi-2.3.so.0.2.16 libc.so.6 => /lib/libc.so.6 (0x00002adf05784000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) undefined symbol: slap_schema (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming (./libslapi-2.3.so.0.2.16) undefined symbol: ch_mfuncs (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_extended (./libslapi-2.3.so.0.2.16) undefined symbol: slap_cids (./libslapi-2.3.so.0.2.16) undefined symbol: slap_unknown_bv (./libslapi-2.3.so.0.2.16) undefined symbol: frontendDB (./libslapi-2.3.so.0.2.16) undefined symbol: sockbuf_max_incoming_auth (./libslapi-2.3.so.0.2.16) undefined symbol: local_ssf (./libslapi-2.3.so.0.2.16) undefined symbol: slap_debug (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog_level (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_syslog (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_ldap_result (./libslapi-2.3.so.0.2.16) undefined symbol: slap_send_search_reference (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str_mutex (./libslapi-2.3.so.0.2.16) undefined symbol: be_isroot (./libslapi-2.3.so.0.2.16) undefined symbol: slapi_plugins_used (./libslapi-2.3.so.0.2.16) undefined symbol: be_slurp_update (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_init (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_broadcast (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: lutil_strcopy (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_check (./libslapi-2.3.so.0.2.16) undefined symbol: value_add_one (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize_one (./libslapi-2.3.so.0.2.16) undefined symbol: rdn_validate (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_pool_context (./libslapi-2.3.so.0.2.16) undefined symbol: ber_dupbv (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_extop (./libslapi-2.3.so.0.2.16) undefined symbol: attr_merge_normalize (./libslapi-2.3.so.0.2.16) undefined symbol: ch_free (./libslapi-2.3.so.0.2.16) undefined symbol: modify_add_values (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_signal (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_unlock (./libslapi-2.3.so.0.2.16) undefined symbol: be_issuffix (./libslapi-2.3.so.0.2.16) undefined symbol: ch_calloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_sl_free (./libslapi-2.3.so.0.2.16) undefined symbol: anlist2charray_x (./libslapi-2.3.so.0.2.16) undefined symbol: ch_strdup (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: value_match (./libslapi-2.3.so.0.2.16) undefined symbol: slap_str2ad (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_is_inst (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvfree (./libslapi-2.3.so.0.2.16) undefined symbol: is_ad_subtype (./libslapi-2.3.so.0.2.16) undefined symbol: access_allowed_mask (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: dnExtractRdn (./libslapi-2.3.so.0.2.16) undefined symbol: send_ldap_sasl (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_dup (./libslapi-2.3.so.0.2.16) undefined symbol: register_supported_control (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods2entry (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_wait (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_add (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_get_rw (./libslapi-2.3.so.0.2.16) undefined symbol: dnPrettyNormal (./libslapi-2.3.so.0.2.16) undefined symbol: select_backend (./libslapi-2.3.so.0.2.16) undefined symbol: dnParent (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlerror (./libslapi-2.3.so.0.2.16) undefined symbol: attr_delete (./libslapi-2.3.so.0.2.16) undefined symbol: be_entry_release_rw (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_bv2dn (./libslapi-2.3.so.0.2.16) undefined symbol: str2entry (./libslapi-2.3.so.0.2.16) undefined symbol: dnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_initialize (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_lock (./libslapi-2.3.so.0.2.16) undefined symbol: get_supported_controls (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlclose (./libslapi-2.3.so.0.2.16) undefined symbol: entry_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: slap_parse_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: entry2str (./libslapi-2.3.so.0.2.16) undefined symbol: entry_dup (./libslapi-2.3.so.0.2.16) undefined symbol: slap_entry2mods (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_op_walk (./libslapi-2.3.so.0.2.16) undefined symbol: rdnNormalize (./libslapi-2.3.so.0.2.16) undefined symbol: str2filter (./libslapi-2.3.so.0.2.16) undefined symbol: filter_free (./libslapi-2.3.so.0.2.16) undefined symbol: attr_find (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_alloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_rdn2bv (./libslapi-2.3.so.0.2.16) undefined symbol: entry_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_dnfree (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_str2rdn (./libslapi-2.3.so.0.2.16) undefined symbol: dnIsSuffix (./libslapi-2.3.so.0.2.16) undefined symbol: rdnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: ber_bvarray_free (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_unbind_ext_s (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_charray_free (./libslapi-2.3.so.0.2.16) undefined symbol: test_filter (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlopen (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_register (./libslapi-2.3.so.0.2.16) undefined symbol: modify_delete_values (./libslapi-2.3.so.0.2.16) undefined symbol: attr_free (./libslapi-2.3.so.0.2.16) undefined symbol: backend_connection_init (./libslapi-2.3.so.0.2.16) undefined symbol: build_new_dn (./libslapi-2.3.so.0.2.16) undefined symbol: entry_schema_check (./libslapi-2.3.so.0.2.16) undefined symbol: ad_inlist (./libslapi-2.3.so.0.2.16) undefined symbol: filter2bv_x (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_mutex_init (./libslapi-2.3.so.0.2.16) undefined symbol: ber_sockbuf_ctrl (./libslapi-2.3.so.0.2.16) undefined symbol: attr_dup (./libslapi-2.3.so.0.2.16) undefined symbol: connection_assign_nextid (./libslapi-2.3.so.0.2.16) undefined symbol: ch_realloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_controls_free (./libslapi-2.3.so.0.2.16) undefined symbol: mods_structural_class (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlsym (./libslapi-2.3.so.0.2.16) undefined symbol: filter_dup (./libslapi-2.3.so.0.2.16) undefined symbol: dnPretty (./libslapi-2.3.so.0.2.16) undefined symbol: slap_bv2ad (./libslapi-2.3.so.0.2.16) undefined symbol: acl_check_modlist (./libslapi-2.3.so.0.2.16) undefined symbol: dnMatch (./libslapi-2.3.so.0.2.16) undefined symbol: slap_mods_free (./libslapi-2.3.so.0.2.16) undefined symbol: ch_malloc (./libslapi-2.3.so.0.2.16) undefined symbol: ldap_pvt_thread_cond_destroy (./libslapi-2.3.so.0.2.16) undefined symbol: lt_dlinit (./libslapi-2.3.so.0.2.16) undefined symbol: overlay_config (./libslapi-2.3.so.0.2.16)

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> As far as I remember, that test is intended to prevent mapping when the >> search returns more than one entry. This makes perfectly sense, >> otherwise a SASL identity (or an authorization identity) would be >> arbitrarily mapped to one of the matching entries. So mapping is >> intended to succeed if and only if exactly one identity can be resolved. > > That test is only supposed to prevent mapping when doing an authzRegexp > mapping of a single SASL userID to a DN. When looking up > authzFrom/authzTo it is supposed to allow multiple results. > Interestingly, it looks like slap_sasl_match isn't even used for > authzRegexp mapping any more. Something is definitely broken here. > This behavior was changed in rev 1.126 of saslauthz.c. I believe the relevant portions of that patch need to be reverted. e.g. patch -R: diff -u -r1.125 -r1.126 --- saslauthz.c 26 Apr 2004 19:47:02 -0000 1.125 +++ saslauthz.c 26 Apr 2004 20:47:08 -0000 1.126 @@ -772,14 +802,26 @@ { smatch_info *sm = o->o_callback->sc_private; - if (rs->sr_type != REP_SEARCH) return 0; + if ( rs->sr_type != REP_SEARCH ) { + if ( rs->sr_err != LDAP_SUCCESS ) { + sm->match = -1; + } + return 0; + } + + if ( sm->match == 1 ) { + sm->match = -1; + return 0; + } if (dn_match(sm->dn, &rs->sr_entry->e_nname)) { sm->match = 1; - return -1; /* short-circuit the search */ + + } else { + sm->match = -1; } - return 1; + return 0; } /* @@ -984,7 +1026,7 @@ op.o_bd->be_search( &op, &rs ); - if (sm.match) { + if (sm.match == 1) { rc = LDAP_SUCCESS; } else { rc = LDAP_INAPPROPRIATE_AUTH; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > sylvain(a)pilotsystems.net wrote: >> Full_Name: Sylvain Viollon >> Version: 2.3 >> OS: FreeBSD 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.204.228.114) >> >> >> >> I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, >> having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) >> having the following attribute : >> >> authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) >> >> He can successfully authenticate, but not become an user listed by the search >> (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the >> last user returned by the search. >> >> In source, I read the file 'servers/slapd/saslauthz.c'. The filter >> 'sasl_sc_smatch' said if the wanted user is in the search result. In this >> function, there is a test : >> >> if ( sm->match == 1 ) { >> sm->match = -1; >> return 0; >> } >> >> I have removed the line : >> >> sm->match = -1; >> >> Which make the match to fail if there is an entry in the search return after the >> good one. Like every DN have to be unique, there is no multiple solution, and >> validation would not be discarded for that. I didn't know if it's a good >> solution, but it's work. >> >> > As far as I remember, that test is intended to prevent mapping when the > search returns more than one entry. This makes perfectly sense, > otherwise a SASL identity (or an authorization identity) would be > arbitrarily mapped to one of the matching entries. So mapping is > intended to succeed if and only if exactly one identity can be resolved. That test is only supposed to prevent mapping when doing an authzRegexp mapping of a single SASL userID to a DN. When looking up authzFrom/authzTo it is supposed to allow multiple results. Interestingly, it looks like slap_sasl_match isn't even used for authzRegexp mapping any more. Something is definitely broken here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by ando＠sys-net.it 11 Nov '06

11 Nov '06

sylvain(a)pilotsystems.net wrote: > Full_Name: Sylvain Viollon > Version: 2.3 > OS: FreeBSD 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.204.228.114) > > > > I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, > having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) > having the following attribute : > > authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) > > He can successfully authenticate, but not become an user listed by the search > (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the > last user returned by the search. > > In source, I read the file 'servers/slapd/saslauthz.c'. The filter > 'sasl_sc_smatch' said if the wanted user is in the search result. In this > function, there is a test : > > if ( sm->match == 1 ) { > sm->match = -1; > return 0; > } > > I have removed the line : > > sm->match = -1; > > Which make the match to fail if there is an entry in the search return after the > good one. Like every DN have to be unique, there is no multiple solution, and > validation would not be discarded for that. I didn't know if it's a good > solution, but it's work. > > As far as I remember, that test is intended to prevent mapping when the search returns more than one entry. This makes perfectly sense, otherwise a SASL identity (or an authorization identity) would be arbitrarily mapped to one of the matching entries. So mapping is intended to succeed if and only if exactly one identity can be resolved. If the behavior you're experiencing is consistent with the above, there is no evidence of a bug in OpenLDAP software. If it's not, please detail. Otherwise, this ITS will be closed. p. Unless Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4744) Bug in SASL authzTo validation using an ldap:// rule
by sylvain＠pilotsystems.net 11 Nov '06

11 Nov '06

Full_Name: Sylvain Viollon Version: 2.3 OS: FreeBSD 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.204.228.114) I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) having the following attribute : authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) He can successfully authenticate, but not become an user listed by the search (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the last user returned by the search. In source, I read the file 'servers/slapd/saslauthz.c'. The filter 'sasl_sc_smatch' said if the wanted user is in the search result. In this function, there is a test : if ( sm->match == 1 ) { sm->match = -1; return 0; } I have removed the line : sm->match = -1; Which make the match to fail if there is an entry in the search return after the good one. Like every DN have to be unique, there is no multiple solution, and validation would not be discarded for that. I didn't know if it's a good solution, but it's work. Openldap 2.2 and 2.4 seems to have the same problem.

1 0

ITS#3755 strict aliasing rules
by hyc＠symas.com 11 Nov '06

11 Nov '06

Compiling current HEAD with gcc 4.1.1 make AC_CFLAGS="-g -fstrict-aliasing -O3 -Wstrict-aliasing" -j3 CC=gcc turned up a few "will break strict-aliasing rules" warnings: libldap/cyrus.c libldap/getdn.c clients/tools/ldapsearch.c servers/slapd/sasl.c I've silenced all of those. Whether the code was actually unsafe before and is safer now is anybody's guess; I was unable to get any of it to misbehave with various combinations of optimization switches. There are warnings about using the BerElementBuffer "might break strict-aliasing rules" which I've chosen to ignore. Since the memory is only actually referenced through the BerElement pointer, whether or not the contents are defined when accessing the BerElementBuffer is irrelevant. (I.e., we never access it that way, so it's moot.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 10 Nov '06

10 Nov '06

michael(a)stroeder.com wrote: > It seems that slapd stops without configuration error message if unknown > attribute types are set for parameter unique_attributes (slapo-unique). It would > be nice if a descriptive message is displayed (like in other cases). > I think this occurs if debug is set to "config" or "-1". However, it would be more appropriate to log configuration errors that result in failures at "any", so that whatever logging is set they show up. For this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that they show up when caught by tools with default logging (e.g. slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. I'd vote for the latter. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4743) ldapsearch manpage Project reference
by quanah＠stanford.edu 10 Nov '06

10 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28/2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The ldapsearch(1) man page was sync'd for the 2.3.28 release, and inadverdently included a reference to the "Projects" file, which is a HEAD specific bit.

1 0

(ITS#4742) parameter unique_attributes and unknown attribute types
by michael＠stroeder.com 10 Nov '06

10 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.25.247) HI! It seems that slapd stops without configuration error message if unknown attribute types are set for parameter unique_attributes (slapo-unique). It would be nice if a descriptive message is displayed (like in other cases). Ciao, Michael.

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 10 Nov '06

10 Nov '06

Eric Covener wrote: > On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: >> covener(a)gmail.com wrote: >> > FWIW, Another SDK I'm working with exposes a once-per-process SSL >> > initialization method, that would amount to ldap_pvt_tls_init(); >> >> A fix for this is in HEAD, please test. > > Now working for me on HEAD: > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); > ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); > > ld1 = ldap_init(h,p); > ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); > ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); > ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); > > ld2 = ldap_init(h,p); > > and connections to ld1 and ld2 send the right client cert over the > wire. Hope this is a resonable API usage -- Much appreciated! > Thanks for the confirmation. The is_server flag only needs to be set non-zero if you are going to be accepting incoming TLS sessions with that context. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 10 Nov '06

10 Nov '06

On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: > covener(a)gmail.com wrote: > > FWIW, Another SDK I'm working with exposes a once-per-process SSL > > initialization method, that would amount to ldap_pvt_tls_init(); > > A fix for this is in HEAD, please test. Now working for me on HEAD: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); ld1 = ldap_init(h,p); ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); ld2 = ldap_init(h,p); and connections to ld1 and ld2 send the right client cert over the wire. Hope this is a resonable API usage -- Much appreciated! -- Eric Covener covener(a)gmail.com

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

covener(a)gmail.com wrote: > FWIW, Another SDK I'm working with exposes a once-per-process SSL > initialization method, that would amount to ldap_pvt_tls_init(); A fix for this is in HEAD, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

FWIW, Another SDK I'm working with exposes a once-per-process SSL initialization method, that would amount to ldap_pvt_tls_init();

1 0

(ITS#4739)
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1558012606-1163097706=:73509 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies for the breach of etiqette. Will change the backend.=0A=0A -k= ph=0A=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ADo you Yahoo!?=0AEveryone is raving = about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com --0-1558012606-1163097706=:73509 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div>Apologies for the breach of etiqette.  Will change the backe= nd.<br><br>    -kph<br><br><br></div></div><br>=0A=0A=0A<hr = size=3D1>Everyone is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D4= 2297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail= beta.</a></body></html> --0-1558012606-1163097706=:73509--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 2:20 AM +0000 lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() > function, which is assigned at line 522. The next if-then-else block is > checking to see if the module reported an error, at which point 'ok' > would be assigned LDAP_OTHER regardless of what check_password() > returned. A superfluous else block appears after this check, assigning > 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. Howard checked in a fix to HEAD for this last night, please test. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4739) Server crashes every time alias is dereferenced
by quanah＠stanford.edu 09 Nov '06

09 Nov '06

--On Thursday, November 09, 2006 5:08 PM +0000 hardimankevin(a)yahoo.com wrote: > --0-1753053770-1163092074=:90949 > Content-Type: text/plain; charset=ascii > Content-Transfer-Encoding: quoted-printable > > Buchan,=0A=0ANot sure what to say - I can reproduce this error with the > Man= driva packages and from source (which leads me to believe it has > nothing to= do with the packaging) with a 100% rate. I had sent Howard > Chu an email l= ast night with much more detail; if you'd like me to > forward that I will.= =0A=0A -kph=0A=0A=0A----- Original Message > You should send responses with more detail to the ITS, not to individual people. This allows all developers and other involved to have the full information. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs