openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#5060) slapi_entry_dup and leak
by m.d.t.evans＠qmul.ac.uk 23 Jul '07

23 Jul '07

Full_Name: Martin Evans Version: 2.3.37 OS: Linux/fc6 URL: ftp://ftp.openldap.org/incoming/addressbook.c Submission from: (NULL) (138.37.8.140) This problem seems similar to the solution suggested for ITS#4038. Id like to add an attribute to an entry in the result set during a SLAPI_PLUGIN_PRE_ENTRY_FN callback. According to 4038 the entry should be dupped. But I cannot free the entry afterwards without problems, and if I dont do that the server leaks memory at a high rate. I've left an example plugin in your ftp incoming directory as addressbook.c. The crucial bit of code is this: slapi_pblock_get(pb,SLAPI_SEARCH_RESULT_ENTRY,&e0); cn = slapi_entry_attr_get_charptr(e0, "cn"); DEBUG("found: %s",cn); /* dup the entry - leaks!! */ e1=slapi_entry_dup(e0); if (e1==NULL) { LOG("addressbook_result_entry failed to duplicate entry"); return PLUGIN_STOP; } slapi_entry_attr_set_charptr(e1,"telephoneNumber","12345"); /* set the dupped entry as the result */ slapi_pblock_set(pb, SLAPI_SEARCH_RESULT_ENTRY, e1); /* uncomment this for empty result set, otherwise leaks */ //slapi_entry_free(e1); /* uncomment this for crash */ //slapi_entry_free(e0); If I free e1, I get null results via an ldap search (only "dn:" is displayed for each entry. If I do that there is no leak. If I free e0 (not sure what handles that after the pblock_set call) the server crashes. Kind regards, Martin.

1 0

(ITS#5058) LDAP/Egroupware addressbook issue
by chandra＠sentienthealth.com 22 Jul '07

22 Jul '07

Full_Name: M.G.Chandra Babu Version: LDAPv3 OS: Linux - SuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.185.109.242) We are using latest Egroupware, and when we try to edit the address book entry, it hang, see the ldap log file : Jul 23 13:39:34 shs slapd[20739]: conn=165 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" mech=SIMPLE ssf=0 Jul 23 13:39:34 shs slapd[20739]: do_bind: v3 bind: "uid=revathy,ou=People,dc=domainname,dc=com" to "uid=revathy,ou=People,dc=domainname,dc=com" Jul 23 13:39:34 shs slapd[20739]: send_ldap_result: conn=165 op=0 p=3 Jul 23 13:39:34 shs slapd[20739]: send_ldap_result: err=0 matched="" text="" Jul 23 13:39:34 shs slapd[20739]: send_ldap_response: msgid=1 tag=97 err=0 Jul 23 13:39:34 shs slapd[20739]: conn=165 op=0 RESULT tag=97 err=0 text= Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: new connection on 18 Jul 23 13:39:35 shs slapd[20739]: conn=166 fd=18 ACCEPT from IP=192.168.1.1:20057 (IP=0.0.0.0:389) Jul 23 13:39:35 shs slapd[20739]: daemon: added 18r Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: 18r Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: read activity on 18 Jul 23 13:39:35 shs slapd[20739]: connection_get(18) Jul 23 13:39:35 shs slapd[20739]: connection_get(18): got connid=166 Jul 23 13:39:35 shs slapd[20739]: connection_read(18): checking for input on id=166 Jul 23 13:39:35 shs slapd[20739]: do_bind Jul 23 13:39:35 shs slapd[20739]: ber_get_next on fd 18 failed errno=11 (Resource temporarily unavailable) Jul 23 13:39:35 shs slapd[20739]: >>> dnPrettyNormal: <uid=revathy,ou=People,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: <<< dnPrettyNormal: <uid=revathy,ou=People,dc=domainname,dc=com>, <uid=revathy,ou=people,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: do_bind: version=3 dn="uid=revathy,ou=People,dc=domainname,dc=com" method=128 Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" method=128 Jul 23 13:39:35 shs slapd[20739]: ==> bdb_bind: dn: uid=revathy,ou=People,dc=domainname,dc=com Jul 23 13:39:35 shs slapd[20739]: bdb_dn2entry("uid=revathy,ou=people,dc=domainname,dc=com") Jul 23 13:39:35 shs slapd[20739]: => access_allowed: auth access to "uid=revathy,ou=People,dc=domainname,dc=com" "userPassword" requested Jul 23 13:39:35 shs slapd[20739]: => dn: [1] Jul 23 13:39:35 shs slapd[20739]: => dn: [2] cn=subschema Jul 23 13:39:35 shs slapd[20739]: => acl_get: [3] attr userPassword Jul 23 13:39:35 shs slapd[20739]: => acl_mask: access to entry "uid=revathy,ou=People,dc=domainname,dc=com", attr "userPassword" requested Jul 23 13:39:35 shs slapd[20739]: => acl_mask: to all values by "", (=n) Jul 23 13:39:35 shs slapd[20739]: <= check a_dn_pat: self Jul 23 13:39:35 shs slapd[20739]: <= check a_dn_pat: * Jul 23 13:39:35 shs slapd[20739]: <= acl_mask: [2] applying auth(=x) (stop) Jul 23 13:39:35 shs slapd[20739]: <= acl_mask: [2] mask: auth(=x) Jul 23 13:39:35 shs slapd[20739]: => access_allowed: auth access granted by auth(=x) Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" mech=SIMPLE ssf=0 Jul 23 13:39:35 shs slapd[20739]: do_bind: v3 bind: "uid=revathy,ou=People,dc=domainname,dc=com" to "uid=revathy,ou=People,dc=domainname,dc=com" Jul 23 13:39:35 shs slapd[20739]: send_ldap_result: conn=166 op=0 p=3 Jul 23 13:39:35 shs slapd[20739]: send_ldap_result: err=0 matched="" text="" Jul 23 13:39:35 shs slapd[20739]: send_ldap_response: msgid=1 tag=97 err=0 Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 RESULT tag=97 err=0 text= Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: 18r Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: read activity on 18 Jul 23 13:39:35 shs slapd[20739]: connection_get(18) Jul 23 13:39:35 shs slapd[20739]: connection_get(18): got connid=166 Jul 23 13:39:35 shs slapd[20739]: connection_read(18): checking for input on id=166 Jul 23 13:39:35 shs slapd[20739]: do_search Jul 23 13:39:35 shs slapd[20739]: >>> dnPrettyNormal: <o=sen,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: <<< dnPrettyNormal: <o=sen,dc=domainname,dc=com>, <o=sen,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: SRCH "o=sen,dc=domainname,dc=com" 2 0 Jul 23 13:39:35 shs slapd[20739]: 300 0 0 Jul 23 13:39:35 shs slapd[20739]: begin get_filter Jul 23 13:39:35 shs slapd[20739]: OR Jul 23 13:39:35 shs slapd[20739]: begin get_filter_list Jul 23 13:39:35 shs slapd[20739]: begin get_filter Jul 23 13:39:35 shs slapd[20739]: EQUALITY Its stop here and hang and we have to restart ldap to make it work.

1 0

(ITS#5057) AVA_Sort doesn't
by hyc＠OpenLDAP.org 22 Jul '07

22 Jul '07

Full_Name: Howard Chu Version: 2.1+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.95.127.34) Submitted by: hyc The AVA_Sort function hasn't really been touched much since it was written in December 2001. It appears that it only works for sorting RDNs with two AVAs or less. With 3 or more, it stops prematurely.

1 0

Re: (ITS#5040) modifyTimestamp being updated on login (bind) failure
by hyc＠symas.com 22 Jul '07

22 Jul '07

hyc(a)symas.com wrote: > Dan Cushing wrote: >> I'd defer to those with more expertise, but my vote is to avoid changing >> the modifyTimestamp attribute. That attribute should be updated only >> when an ldapmodify operation is performed. >> >> I'm not familiar with the specifications, and perhaps this isn't >> addressed there. My intuition suggests that it shouldn't be modified by >> operations that are not directly under the control of the user or >> administrator. > > Already fixed in CVS HEAD and RE23, please test. I'll note that this change will prevent these operational attributes from being replicated in many cases. Of course, given that the replication behavior of these attributes is currently undefined, it may not be a problem right now. Down the road, I don't know. -- -- 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#5040) modifyTimestamp being updated on login (bind) failure
by hyc＠symas.com 22 Jul '07

22 Jul '07

Dan Cushing wrote: > I'd defer to those with more expertise, but my vote is to avoid changing > the modifyTimestamp attribute. That attribute should be updated only > when an ldapmodify operation is performed. > > I'm not familiar with the specifications, and perhaps this isn't > addressed there. My intuition suggests that it shouldn't be modified by > operations that are not directly under the control of the user or > administrator. Already fixed in CVS HEAD and RE23, please test. -- -- 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#5040) modifyTimestamp being updated on login (bind) failure
by dan.cushing＠netideasinc.com 22 Jul '07

22 Jul '07

I'd defer to those with more expertise, but my vote is to avoid changing the modifyTimestamp attribute. That attribute should be updated only when an ldapmodify operation is performed. I'm not familiar with the specifications, and perhaps this isn't addressed there. My intuition suggests that it shouldn't be modified by operations that are not directly under the control of the user or administrator. Dan Howard Chu wrote: > dan.cushing(a)netideasinc.com wrote: >> Full_Name: Dan Cushing >> Version: 2.3.36 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (71.76.187.82) >> >> >> When running OpenLDAP with the ppolicy overlay, the modifyTimestamp >> for a user >> entry is updated if the user attempts to login (bind) with an incorrect >> password. This is happening because the password lockout feature is >> enabled and >> the operational attribute 'pwdFailureTime' is being updated. It >> seems like this >> results in a misleading modifyTimestamp. Is it intended that the >> modifyTimestamp attribute be updated when operational attributes are >> updated? > > Hadn't really thought about it before. We can certainly avoid this > though. -- This electronic transmission is strictly confidential to NetIDEAS, Inc. and intended solely for the addressee. It may contain information, which is covered by legal, professional, or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on the behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify us as soon as possible and destroy this message.

1 0

ITS#5028 incomplete slapcat docs
by hyc＠symas.com 22 Jul '07

22 Jul '07

> From: Gavin Henry <openldap-its(a)OpenLDAP.org> > Date: Fri Jul 13 18:19:25 2007 > > The same sentance is in slapadd(8)/slapindex(8) too. That is correct; slapadd/slapindex must never be run while slapd is running. -- -- 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

ITS#5009 ldapsearch -C
by hyc＠symas.com 22 Jul '07

22 Jul '07

As noted elsewhere, the "-C" option is intentionally undocumented. Since the command line tools only support anonymous referral chasing, and referral chasing through untrusted servers is inherently unsafe, it's best not to do it. 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#5040) modifyTimestamp being updated on login (bind) failure
by hyc＠symas.com 22 Jul '07

22 Jul '07

dan.cushing(a)netideasinc.com wrote: > Full_Name: Dan Cushing > Version: 2.3.36 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.76.187.82) > > > When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user > entry is updated if the user attempts to login (bind) with an incorrect > password. This is happening because the password lockout feature is enabled and > the operational attribute 'pwdFailureTime' is being updated. It seems like this > results in a misleading modifyTimestamp. Is it intended that the > modifyTimestamp attribute be updated when operational attributes are updated? Hadn't really thought about it before. We can certainly avoid this though. -- -- 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#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠suretecsystems.com 21 Jul '07

21 Jul '07

<quote who="hyc(a)symas.com"> > ando(a)sys-net.it wrote: >> ghenry(a)suretecsystems.com wrote: >>> <quote who="hyc(a)symas.com"> >>>> ghenry(a)OpenLDAP.org wrote: >>>>> Full_Name: Gavin Henry >>>>> Version: HEAD >>>>> OS: >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (80.229.93.1) >>>>> Submitted by: ghenry >>>>> >>>>> >>>>> Dear All, >>>>> >>>>> It's not clear or explained what AVA means in slapd-meta(5) and >>>>> slapo-rwm(5) >>>> Standard terminology in X.500/LDAP. "Attribute Value Assertion" >>>>> A user was asking in #ldap >>>>> >>>>> I presume it means "Attribute Value"? >>>>> >>>>> If so, I will add an explaination in each man page. >>>> OpenLDAP docs are not intended to explain the basics of LDAP. You're >>>> expected >>>> to already know LDAP or refer to the RFCs for basic terminology. >>> Closing ITS. >> >> In any case, expanding acronyms when first used sounds "polite"; any >> further reference to the most appropriate RFC should allow newbie >> readers to learn more. > > Perhaps, in the Admin Guide. We have it in preamble.sdf already, so I think this is covered. > But in the man page? Where do you draw the line? > Do we have to start every man page with e.g. "the meta backend to slapd > (the > Standalone LDAP (Lightweight Directory Access Protocol) Daemon) performs > basic > LDAP proxying..." ? > > In this case, what good would it do? Would someone who hasn't read any > RFCs > know what "Attribute Value Assertion" means? Anyone who doesn't understand > the > X.500 information model has no business administering slapd. They need to > absorb that basic groundwork first, and IMO manpages are not the mechanism > for > teaching that. > -- > -- 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

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