openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

Emmanuel Lecharny wrote: > Howard Chu a écrit : >> This works as designed - requesting an objectclass means to request >> all of the attributes included in that objectclass. In current >> revisions we expect objectClass names to be prefixed with "@" but the >> original behavior is still supported for backward compatibility. >> > Oh... Is there any RFC which expose this intended behaviour ? RFC 4529. This ITS will be closed. -- -- Howard Chu Chief Architect, 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#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.236.207.89) > > > When searching for entries using attributes to filter the result, you get all > the entries attributes if you give a wrong attribute : > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 > > will correctly returns only the DNs of all found entries, as if the 9.9.9 > attribute was 1.1 > > but > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted by "*" > > Of course, 'person' is not an attribute, but an objectClass, but the user intent > was to get only one single attribute value, so I don't think that returning > everything is correct. > > This is obviously not a serious issue. This works as designed - requesting an objectclass means to request all of the attributes included in that objectclass. In current revisions we expect objectClass names to be prefixed with "@" but the original behavior is still supported for backward compatibility. -- -- Howard Chu Chief Architect, 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#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Hallvard B Furuseth a écrit : >elecharny(a)apache.org writes: > > >>ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b >>"dc=example,dc=com" -s sub "(objectClass=*)" person >> >>will return all entries attributes, as if the 'person' was substituted >>by "*" >> >> > >That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): > "If an attribute description in the list is not recognized, it is > ignored by the server." >Ignoring "person" yields an empty list, which works like a "*". > >I'm guessing that's not what it was intended to say though. RFC 1777 >(LDAPv2) did not have it, so 'person' would work like '1.1' does now. > > > Well, RFC 4511 just states that if the attribute is unknow, then it is ignored, but say nothing about using '1.1' or '*' . Ignoring the only attributes given by the user and substitute a '*' to it is a violation of user intent, IMHO (even if this user was wrong when selecting the attribute). RFC 4511 authors didn't thought of such a case, I guess ;) Anyway, OpenLdap behave differently if the attribute is unknown (9.9.9) and when it is known by the server (at least, the OID is known, even if it's not an attribute object), when it should returns always the same result : either '*' or '1.1'. This is not the case, and it's not consistent, whatever RFC 4511 says - or omits to say :) -. Emmanuel

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

elecharny(a)apache.org writes: > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted > by "*" That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): "If an attribute description in the list is not recognized, it is ignored by the server." Ignoring "person" yields an empty list, which works like a "*". I'm guessing that's not what it was intended to say though. RFC 1777 (LDAPv2) did not have it, so 'person' would work like '1.1' does now. -- Regards, Hallvard

1 0

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠suretecsystems.com 22 May '07

22 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >>> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >>> >>> "A 000001010000Z value means that the account has been locked >>> permanently, and >>> that only a password administrator can unlock the account." >>> >>> But pwdAccountLockedTime doesn't use integerMatch, so an example of the >>> above >>> syntax is needed with anything that has a generalizedTimeMatch. I think >>> pwdAccountLockedTime is the only one? >> >> The slapo-ppolicy(5) manpage is actually misleading. It implies that >> the value is a plain zero, which doesn't work: >> "If pwdAccountLockedTime is set to zero (0), the user's account (...)" > > That text in the manpage came from an earlier revision of the ppolicy > draft; it just wasn't updated when the meaning was clarified in a later > draft version. Looks like Gavin has fixed it in HEAD now. Yes, sorry. I thought silence meant it was ok to go ahead. This is my first ever commit, so I'll be a bit more patient next time ;-) Thanks. > > -- > -- Howard Chu > Chief Architect, 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#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 22 May '07

22 May '07

nvoutsin(a)noc.uoa.gr wrote: > While slapd does not segfault anymore, slapd insists to concatenate > unrelated database suffixes during search operations that look for attrs > such as hasSubordinates. > > I mention this here because it seems to be related somehow As I could see it working as expected (by me, at least), I suggest you cook a very simple example, consisting in two slapd.conf (one for the remote server, and one for the offending mixed local-proxy-relay setup), and as many data in LDIF format and submit it, so that you can show what you consider an incorrect behavior. Otherwise, I don't see any further indication of a bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by krause＠biochem.mpg.de 22 May '07

22 May '07

I have downloaded the cvs version (2007-05-21) and built it, but get, as it seems related to something else, a segfault. i reproduced this trice. what i did: (just to be sure i did not make a fatal mistake) * fetched cvs * ran configure with the following command line: env CPPFLAGS=-I/usr/include/db42 ./configure --enable-wrappers --enable-aclgroups --enable-spasswd --enable-modules --enable-shared --enable-dynamic --with-tls --with-cyrus-sasl --enable-crypt --enable-aci --enable-bdb --enable-hdb --enable-ldbm --enable-rewrite --enable-ldap=yes --enable-meta=mod --enable-monitor=yes --enable-perl=mod --enable-slp --enable-overlays=yes --enable-lmpasswd --with-yielding-select --enable-debug=yes i had to install the development package for BDB 4.2 (although the rpm from opensuse has it built with BDB 4.3, also i could not reuse the existing ldap db) * then make depend; make; make test -> all tests succeded (as far is i can tell) * gdb openldap/servers/slapd/.libs/slapd run -h ldap:/// ldaps:/// -g ldap -u ldap -d 65535 as the "local" ldap db on this consumer is empty the replication starts (reproduced after segfault and removal of the direcory contents): [lot of debugging output, and finally:] entry_decode: "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" <= entry_decode(cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de) => test_filter PRESENT => access_allowed: search access to "cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 nonpresent_callback: rid=013 got UUID 1f1b0732-9823-102b-8c9e-b3c3d9320a55, dn cn=Neurobiologie EDV,ou=IT Contacts,ou=ACL,dc=biochem,dc=mpg,dc=de send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" bdb_modify: dc=biochem,dc=mpg,dc=de bdb_dn2entry("dc=biochem,dc=mpg,dc=de") entry_decode: "dc=biochem,dc=mpg,dc=de" <= entry_decode(dc=biochem,dc=mpg,dc=de) bdb_modify_internal: 0x00000001: dc=biochem,dc=mpg,dc=de <= acl_access_allowed: granted to database root bdb_modify_internal: add contextCSN => entry_encode(0x00000001): dc=biochem,dc=mpg,dc=de bdb_modify: updated id=00000001 dn="dc=biochem,dc=mpg,dc=de" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225942112 (LWP 19016)] slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 327 new->sids[i] = src->sids[i]; the backtrace says: (gdb) bt #0 slap_dup_sync_cookie (dst=0x8283400, src=0xb6ed8cf0) at ldapsync.c:327 #1 0x080c83fd in syncrepl_updateCookie (si=0x8283310, op=0xb6ed8e7c, pdn=<value optimized out>, syncCookie=0xb6ed8cf0) at syncrepl.c:2615 #2 0x080ced95 in do_syncrep2 (op=0xb6ed8e7c, si=0x8283310) at syncrepl.c:1016 #3 0x080cffbc in do_syncrepl (ctx=0xb6ed92d8, arg=0x8282d60) at syncrepl.c:1161 #4 0x08074c0a in connection_read_thread (ctx=0xb6ed92d8, argv=0x11) at connection.c:1273 #5 0xb7f5f7f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #6 0xb7c4134b in start_thread () from /lib/libpthread.so.0 #7 0xb7bd965e in clone () from /lib/libc.so.6 (gdb) after this it also segfaults if started again : [lot of debugging output, and finally:] do_syncrep2: rid=013 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT ber_scanf fmt (t{) ber: ber_dump: buf=0x08312178 ptr=0x08312178 end=0x083121a8 len=48 0000: a2 2e 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 ...,csn=20070516 0010: 31 38 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 180048Z#000065#0 0020: 30 23 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 0#000000,rid=013 ber_scanf fmt (m) ber: ber_dump: buf=0x08312178 ptr=0x0831217a end=0x083121a8 len=46 0000: 04 2c 63 73 6e 3d 32 30 30 37 30 35 31 36 31 38 .,csn=2007051618 0010: 30 30 34 38 5a 23 30 30 30 30 36 35 23 30 30 23 0048Z#000065#00# 0020: 30 30 30 30 30 30 2c 72 69 64 3d 30 31 33 000000,rid=013 ber_scanf fmt (}) ber: ber_dump: buf=0x08312178 ptr=0x083121a8 end=0x083121a8 len=0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1235027040 (LWP 23928)] compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 647 if ( sc1->sids[i] != sc2->sids[j] ) backtrace says this time: (gdb) bt #0 compare_csns (sc1=0xb662ecd0, sc2=0xb662ecf0, which=0xb662ede4) at syncrepl.c:647 #1 0x080ced4c in do_syncrep2 (op=0xb662ee7c, si=0x82832b0) at syncrepl.c:1005 #2 0x080cffbc in do_syncrepl (ctx=0xb662f2d8, arg=0x8282d00) at syncrepl.c:1161 #3 0x08074c0a in connection_read_thread (ctx=0xb662f2d8, argv=0x11) at connection.c:1273 #4 0xb7eb67f2 in ldap_int_thread_pool_wrapper (xpool=0x821ff08) at tpool.c:725 #5 0xb7b9834b in start_thread () from /lib/libpthread.so.0 #6 0xb7b3065e in clone () from /lib/libc.so.6 * the configuration on the provider and the consumer were left untouched (except path corrections) to the until now running without errors rpm-version 2.3.34, the old rpms have been removed (using rpm -e) did i make something wrong or did i hit another bug?? regards markus Zitat von Pierangelo Masarati <ando(a)sys-net.it>: > This is now completely fixed in HEAD; I need to check any issue related > to backporting to re23, for quick release. Please test. Thanks for > reporting, p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > +-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause(a)biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause(a)mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause(a)mac.com | +--------------------------------+--------------------------------+ ---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux(a)biochem.mpg.de

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 22 May '07

22 May '07

While slapd does not segfault anymore, slapd insists to concatenate unrelated database suffixes during search operations that look for attrs such as hasSubordinates. I mention this here because it seems to be related somehow Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: > >> As ando already said: >> .....it tries to lookup a database to relay for when unbinding, >> but unbind has no DN, so a strcmp on NULL is performed. This does not >> happen when using the "relay" directive because relay database selection >> does not occur for each operation.... > > Technically, the bug is now fixed in HEAD/re23 (please test). > Concerning the issue initially raised on the -software list, which seems > to be open yet, see discussion on the list. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > >

1 0

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by hyc＠symas.com 22 May '07

22 May '07

ahasenack(a)terra.com.br wrote: > On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >> >> "A 000001010000Z value means that the account has been locked permanently, and >> that only a password administrator can unlock the account." >> >> But pwdAccountLockedTime doesn't use integerMatch, so an example of the above >> syntax is needed with anything that has a generalizedTimeMatch. I think >> pwdAccountLockedTime is the only one? > > The slapo-ppolicy(5) manpage is actually misleading. It implies that > the value is a plain zero, which doesn't work: > "If pwdAccountLockedTime is set to zero (0), the user's account (...)" That text in the manpage came from an earlier revision of the ppolicy draft; it just wasn't updated when the meaning was clarified in a later draft version. Looks like Gavin has fixed it in HEAD now. -- -- Howard Chu Chief Architect, 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#4978) slapo-ppolicy.5 and missing Zero value example
by ahasenack＠terra.com.br 22 May '07

22 May '07

On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: > draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: > > "A 000001010000Z value means that the account has been locked permanently, and > that only a password administrator can unlock the account." > > But pwdAccountLockedTime doesn't use integerMatch, so an example of the above > syntax is needed with anything that has a generalizedTimeMatch. I think > pwdAccountLockedTime is the only one? The slapo-ppolicy(5) manpage is actually misleading. It implies that the value is a plain zero, which doesn't work: "If pwdAccountLockedTime is set to zero (0), the user's account (...)"

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs