openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by Philippe.eychart＠informatique.gov.pf 03 Feb '09

03 Feb '09

Full_Name: Philippe EYCHART Version: 2.4.13 OS: slack12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.82.141) Hi, The "tool_conn_setup" function (in common.c) autorise the Url synthaxe "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server to request (not yet according the rfc 2782 - I've made dnssrv.c patch to implement priorities and I try to implement weight before submit this work). So, the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via "ldap_dn2domain" and "ldap_domain2hostlist" functions). Unfortunately, ldap_initialize() doesn't use these functions (but only ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages (like SAMBA) doesn't enjoy this capability : "passdb backend = ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition "_ldap._tcp.my.domain. IN SRV ..." Is there any reason for that ? Can we envisage to increase this possibility ? Regards

1 0

(ITS#5918) slapacl(8c) badly worded
by quanah＠zimbra.com 03 Feb '09

03 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Slapacl is used to check the behavior of the slapd in verifying access to data according to ACLs, as specified in slapd.access(5). It opens the slapd.conf(5) configuration file, reads in the access directives, and then parses the attr list given on the command-line; if none is given, access to the entry pseudo-attribute is tested. Besides the bit about "of the slapd", the first sentence is rather awkward.

1 0

RE: (ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com 03 Feb '09

03 Feb '09

Hi We have tested the solution. It works OK. Greetings, Jorge. -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: jueves, 29 de enero de 2009 20:34 To: Jorge Nevado Cc: openldap-its(a)openldap.org Subject: Re: (ITS#5912) Meta modify increment feature Fixed in HEAD; please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times
by hyc＠symas.com 03 Feb '09

03 Feb '09

ssnet(a)ua.es wrote: > Full_Name: maria saez > Version: 2.4.8 > OS: debian etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.145.230.2) > > > > An account locked in a consumer needs two password changes in the provider to be > unlocked. I'm unable to reproduce this behavior in current code. > The first time that we change the password in the provider the password change > is replicated in the consumer but the account remains locked. A single password change on the provider results in unlocking on the consumer for me. > > Can you help us? > We have openldap-2.4.7 and openldap-2.4.8 > > Is this situation normal? > > We have the following configuration: > > Provider > ------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > # define the replica provider for this database > # (last directives in database section) > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" > ppolicy_use_lockout > > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > > Consumer > ---------------------------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" > ppolicy_use_lockout > > syncrepl rid=123 > provider=ldaps://xx.xx.es:xx/ > binddn="cn=config" > bindmethod=simple > credentials=xx > searchbase="dc=xx,dc=es" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > overlay syncprov > ------------------------------------------------------------------- > The policy we have defined: > > dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es > cn: Standard Policy > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: 2.5.4.35 > pwdLockout: TRUE > pwdLockoutDuration: 0 > pwdInHistory: 6 > pwdCheckQuality: 2 > pwdExpireWarning: 10 > pwdMaxAge: 120 > pwdMinLength: 5 > pwdGraceAuthnLimit: 3 > pwdAllowUserChange: TRUE > pwdMustChange: TRUE > pwdMaxFailure: 3 > pwdFailureCountInterval: 120 > pwdSafeModify: TRUE > pwdMinAge: 120 > ------------------------------------------------------------- > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5917) slapd crashes with assertion failed and SIGABRT
by guido＠keamera.org 02 Feb '09

02 Feb '09

Full_Name: Guido Landi Version: 2.3.43 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.246.126.62) Hello, I'm using OpenLDAP 2.3.43 with ldap backend as a proxy to Active Directory for users autentication on linux(gentoo). OpenLDAP keep on crashing while testing it through the nss_ldap module using the "id" unix command. It often crashes for an assertion failed(that i can easily reproduce) but sometimes with a segmentation fault or a glibc error related to free()(heap corruption?). I found as a workaround that if I set the maximum threads number to 2 it works just fine. I'm using glibc-2.6.1 with NPTL and I have compiled OpenLDAP with gcc-4.1.2 and 3.4.6. Here is my slapd.conf, ldap.conf(used by the nss_ldap module) and some backtraces. #### slapd.conf #### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/local.schema modulepath /usr/lib/openldap/openldap moduleload rwm overlay rwm rwm-map attribute cn sAMAccountName database ldap suffix "dc=mydomain,dc=it" rootdn "ou=CV Utenti,dc=mydomain,dc=it" lastmod off uri ldaps://mydc.mydomain.it/ rebind-as-user chase-referrals YES index objectClass eq,sub index uidNumber,gidNumber eq index memberUid eq index sAMAccountName eq,subinitial #concurrency 0 #threads 2 TLSCACertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateFile /etc/openldap/ssl/server.pem TLSCertificateKeyFile /etc/openldap/ssl/server.key TLSCipherSuite ALL TLSCRLCheck none TLSReqCert none TLSVerifyClient never #### ldap.conf #### uri ldaps://ldap-proxy.mydomain.it port 636 base OU=mygroup,dc=mydomain,dc=it scope sub binddn CN=myaccount,DC=mydomain,DC=it bindpw password bind_policy soft ldap_version 3 #nss_schema rfc2307bis #debug 1000 REFERRALS no pam_login_attribute cn pam_filter objectClass=user pam_password ad pam_groupdn CN=UNIX Admins,DC=mydomain,DC=it #pam_groupdn CN=UNIX-USERS,DC=mydomain,DC=it pam_member_attribute member nss_base_passwd OU=Users,DC=mydomain,DC=it nss_base_shadow OU=Users,DC=mydomain,DC=it nss_base_group DC=mydomain,DC=it?(objectClass=group) nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid uid nss_map_attribute uniqueMember member #nss_map_attribute uniqueMember msSFU30PosixMemberOf nss_map_attribute userPassword unixUserPassword nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute gecos name nss_map_objectclass posixGroup group nss_reconnect_tries 4 nss_reconnect_sleeptime 1 #nss_reconnect_maxsleeptime 16 nss_reconnect_maxconntries 6 #nss_initgroups backlink #nss_max_group_depth 100 ssl yes #### backtraces #### put_simple_filter: "member=cn=certsvc_dcom_access,cn=users,dc=mydomain,dc=it" ldap_send_initial_request ldap_send_server_request ldap_back_retry: conn 0x826a628 refcnt=2 unable to retry. slapd: bind.c:157: ldap_back_conn_delete: Assertion `!(*(&((lc))->lc_lcflags) & (((0x00000020U))))' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb722eb90 (LWP 25435)] 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0x081147d8 in ldap_back_conn_delete () #4 0x081150e1 in ?? () #5 0x08217930 in ?? () #6 0x0826a628 in ?? () #7 0xb722cde8 in ?? () #8 0x081166f5 in ldap_back_release_conn_lock () Backtrace stopped: frame did not save the PC ber_flush: 104 bytes to sd 11 ldap_result ld 0x825dfb0 msgid 5 ldap_chkResponseList ld 0x825dfb0 msgid 5 all 0 ldap_chkResponseList returns ld 0x825dfb0 NULL Program received signal SIGABRT, Aborted. [Switching to Thread 0xb692db90 (LWP 25728)] 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0xb7f8da8c in ber_flush () from /usr/lib/liblber-2.3.so.0 #4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0 #5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0 #6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0 #7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0 #8 0x080f6eb0 in ldap_back_search () #9 0x08079a9f in fe_op_search () #10 0x080df1fa in overlay_op_walk () #11 0x080df3b1 in ?? () #12 0x082968d0 in ?? () #13 0xb692d18c in ?? () #14 0x00000002 in ?? () #15 0x08217190 in ?? () #16 0x00000000 in ?? () put_simple_filter: "member=cn=unix admins,ou=cv acl,dc=mydomain,dc=it" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: slapd: io.c:210: ber_flush: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )' failed. ** ld 0xb560f238 Response Queue: Empty ldap_chkResponseList ld 0xb560f238 msgid 5 all 0 ldap_chkResponseList returns ld 0xb560f238 NULL ldap_int_select Program received signal SIGABRT, Aborted. [Switching to Thread 0xb722eb90 (LWP 29674)] ---Type <return> to continue, or q <return> to quit--- 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0xb7f8da70 in ber_flush () from /usr/lib/liblber-2.3.so.0 #4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0 #5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0 #6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0 #7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0 #8 0x080f6e10 in ldap_back_search () #9 0x08079a97 in fe_op_search () #10 0x080df15a in overlay_op_walk () #11 0x080df311 in over_op_func () #12 0x080df395 in over_op_search () #13 0x08079549 in do_search () #14 0x0807677a in connection_operation () #15 0xb7fa30a9 in ldap_int_thread_pool_wrapper () from /usr/lib/libldap_r-2.3.so.0 #16 0xb7e5a013 in start_thread () from /lib/libpthread.so.0 #17 0xb7c0948e in clone () from /lib/libc.so.6

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 02 Feb '09

02 Feb '09

michael(a)stroeder.com wrote: > Hmm, maybe I missed something in this discussion and about the usage of > client controls. > > But I'd vote for another function which provides a complete set of > arguments for sending search requests. So if ldap_search_ext is > considered incomplete regarding alias dereferencing I'd vote for > introducing ldap_search_ext2 (or whatever name) with an additional argument. Well, that's ldap_int_search*(); let's vote for the "public" name. As I said, I think it makes sense, since alias dereferencing has always been explicitly required in the request. OTOH, I have no objection to using a client-side control, as it wouldn't add too much complexity (well, it'd require to parse a list of strings with a worst-case of N * M, with N: number of known client controls; M: client controls passed to the request), and it would pave the way for client controls in libldap :) I see Hallvard already has a request for another one. One consideration: I'm not overlooking the value of not changing the API too often; also, I fear client-side controls could be another way to wind up with revitalizing the old API instead of designing a new one - if anyone ever seriously considered the opportunity to design it. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no 01 Feb '09

01 Feb '09

michael(a)stroeder.com writes: > But I'd vote for another function which provides a complete set of > arguments for sending search requests. So if ldap_search_ext is > considered incomplete regarding alias dereferencing I'd vote for > introducing ldap_search_ext2 (or whatever name) with an additional > argument. Yes, the missing aliases argument is an API design bug. The API almost but not quite has functions that match the protocol messages. If we are going to export yet another search function, I'd like to see another feature added as well: A way to pass the BER form of a filter to the search function. And some helpers to build the BER form, and to parse it back into the string form of a filter. Filters are complex enough that it can be a pain to deal with the string form and its quoting at times. Of course, that one could be a client control too - e.g. combined with passing NULL as the filter... -- Hallvard

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by michael＠stroeder.com 01 Feb '09

01 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> ando(a)sys-net.it writes: >>>>> Proxy backends use ldap_set_option(3) to set alias >>>>> dereferencing when requested by a search operation (and do >>>>> not clean it up afterwards, as far as I can tell). Since >>>>> LDAP handlers are pooled and reused, this behavior is >>>>> inherently broken. >> [..] >> I recall complaining about this deficiency in the API back in 1998, >> when I >> first wrote back-ldap. Alias deref has always been a part of the >> protocol, but >> it has always been missing from the API. Perplexing... > > Yes, of course, one might use the client control mechanism to add an > ability to set deref on a call by call basis instead of introducing > yet another function. Hmm, maybe I missed something in this discussion and about the usage of client controls. But I'd vote for another function which provides a complete set of arguments for sending search requests. So if ldap_search_ext is considered incomplete regarding alias dereferencing I'd vote for introducing ldap_search_ext2 (or whatever name) with an additional argument. Ciao, Michael.

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by Kurt＠OpenLDAP.org 31 Jan '09

31 Jan '09

On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> ando(a)sys-net.it writes: >>>> Proxy backends use ldap_set_option(3) to set alias dereferencing >>>> when >>>> requested by a search operation (and do not clean it up >>>> afterwards, as >>>> far as I can tell). Since LDAP handlers are pooled and reused, >>>> this >>>> behavior is inherently broken. >>> I note you committed this with an ldap_int_* interface. >> >> Yes, that's because I needed it internally. > > I think ldap_pvt would make more sense. _int_ means internal to the library. _pvt_ means private to OpenLDAP Software. > I recall complaining about this deficiency in the API back in 1998, > when I > first wrote back-ldap. Alias deref has always been a part of the > protocol, but > it has always been missing from the API. Perplexing... Yes, of course, one might use the client control mechanism to add an ability to set deref on a call by call basis instead of introducing yet another function. > > >>> But it could >>> be useful outside OpenLDAP code too. >> >> Yes, that will probably be the next step. But to make it publicly >> available I should have called it ldap_search_ext2, or >> ldap_search_really_ext or something like that. I think we need to >> make >> it public based on demand and after a ballot on the name. > > Ok. > >>> Seems to me this is what client-side controls are for. Extending >>> the >>> client-side functionality without needing a new API. >> >> Well, since alias dereferencing is part of the protocol, I think >> using a >> client-side control is sort of an overkill :) > > Agreed. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by hyc＠symas.com 31 Jan '09

31 Jan '09

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> Proxy backends use ldap_set_option(3) to set alias dereferencing when >>> requested by a search operation (and do not clean it up afterwards, as >>> far as I can tell). Since LDAP handlers are pooled and reused, this >>> behavior is inherently broken. >> I note you committed this with an ldap_int_* interface. > > Yes, that's because I needed it internally. I think ldap_pvt would make more sense. I recall complaining about this deficiency in the API back in 1998, when I first wrote back-ldap. Alias deref has always been a part of the protocol, but it has always been missing from the API. Perplexing... >> But it could >> be useful outside OpenLDAP code too. > > Yes, that will probably be the next step. But to make it publicly > available I should have called it ldap_search_ext2, or > ldap_search_really_ext or something like that. I think we need to make > it public based on demand and after a ballot on the name. Ok. >> Seems to me this is what client-side controls are for. Extending the >> client-side functionality without needing a new API. > > Well, since alias dereferencing is part of the protocol, I think using a > client-side control is sort of an overkill :) Agreed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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