Full_Name: Kurt Zeilenga
Version: 2.3
OS: Mac OS X
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.129.101.249)
Submitted by: kurt
2.3 (and 2.4) client tools only send the password policy control with the Bind
requests. However, the control is not only valid with most every request, but
useful to send with every request. HEAD has been updated to send, when -e
ppolicy is selected, the control with every request, and to print the control
details on return. While this could be viewed as a new feature by some it could
abe viewed as a bug fix by others. Given this change scope is quite narrow
(should only effect -e ppolicy users), I recommend it inclusion in the next
patch release of 2.3.
Hi Sebastian,
Can you please follow up to this ITS with an IPR release, as detailed at:
<http://www.openldap.org/devel/contributing.html>
thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
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.
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.
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/
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/
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.
> 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/