openldap-bugs December 2010

openldap-bugs@openldap.org

32 participants
128 discussions

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

1 0

Re: (ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 11 Dec '10

11 Dec '10

--=-dGqU1ahV0Ya5KsADLt/0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-dGqU1ahV0Ya5KsADLt/0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJNA/gRAAoJECqLdGgQ4K/B3hQP+wbUpmAAws3D7aobKrff+lm1 fe6Bl2kSh/xr7YJptDHQsQf0u7ZfuWPBY7Jm/VYR6vjBqfn2do2J4yZL2yKbkKJS Js9ir23JBgg5hv/qi9c64uA85GTU0NPex7PcWP45y5Y95ZBtDsdGBzvuoePwGCvn Wkb3dNY1Cl6MDL77CZPyoy1qKRHWcWPfVONhbLkQ5LF2BuDPV1dXjFSV1mqRTbLr JXqn1QKYrdRhHhIkZsdXs8RmdtWZ+43lZyqpF2jGtLR3iP8e55kPluih35Mp/fWM 1L/dVYjQO8sV54b1UPGJKAIDHoqacXhRgCZgRTJxQZy3GJ8eKmuM7G4O71TpYuX5 AoxXDcuSOuBY7qDFfTUkICujNDWHXQ0C4/nzN6owyPc5TneXGeJYMgzmyctZb5et jhLwAuS2kwDGNL46XxyuGSF+cDSEeEFxpewo61cXFB/gp2+469MCWfoyWtyp/LHV MZwpTAz9B0FvDjPMOMqd91h4O1WZIxBBo61FnL2iPWD/pNHrmQXlTTQ/y/WMHIXg bWkjqbnT8Qi1PpFYgvo2u+6oe1U4tV6aNRwioQjVyVi8lK+tyC9EL+tJfAGq5f7H JqOZj37PJ5qd26DUU6q2vX7r7RO7wX8TraP0/Kafvg2FnVk+9G+1LSdmjwzviPBp 32EBHtl1GZlq7rP4Q+zm =74Se -----END PGP SIGNATURE----- --=-dGqU1ahV0Ya5KsADLt/0--

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by hyc＠symas.com 10 Dec '10

10 Dec '10

rmeggins(a)redhat.com wrote: > I "rebased" the patch on top of a recent change: > revision 1.24 > date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 > ITS#6625 Remove some LDAP_R_COMPILEs I didn't quite understand the point of the discussion of SSLv2 clients in the comments on this patch, but committed it anyway. I would hope that nobody is still using SSLv2 these days. Also if a StartTLS request fails, then the rest of the code in tlsm.c should never even be reached; the TLS sockbuf layer wouldn't be installed. > The new patch is here: > ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > > > -- -- 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#6744) memory leak when chasing referrals
by hyc＠symas.com 10 Dec '10

10 Dec '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. Fixed in HEAD. -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 5:16 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' >> DESC 'last successful authentication using any method/mech' >> EQUALITY generalizedTimeMatch >> ORDERING generalizedTimeOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 >> SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) >>=20 >> And we use this attribute in our configuration object to = enable/disable =3D >> (default disabled). >>=20 >> ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' >> DESC 'enable recording of last successful authentication using =3D= >> any method/mech' >> EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 >> SINGLE-VALUE USAGE dsaOperation ) >=20 > Hmm, isn't NAME of the second a little bit confusing since it sounds = like just > the plural of the first? Names should only be for the wire, the wire doesn't get confused. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' > DESC 'last successful authentication using any method/mech' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) > > And we use this attribute in our configuration object to enable/disable = > (default disabled). > > ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' > DESC 'enable recording of last successful authentication using = > any method/mech' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE USAGE dsaOperation ) Hmm, isn't NAME of the second a little bit confusing since it sounds like just the plural of the first? Ciao, Michael.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 12:02 PM, Howard Chu wrote: > Good point. In that case it's probably fine as a separate overlay, the = way it is now. Can we use the schema definition that Isode is using? Not only yes, but hell yes. Reuse and convergence is a good thing. ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' DESC 'last successful authentication using any method/mech' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) And we use this attribute in our configuration object to enable/disable = (default disabled). ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' DESC 'enable recording of last successful authentication using = any method/mech' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dsaOperation )

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > >> On 10/12/10 17:14, Howard Chu wrote: >>> jonathan(a)phillipoux.net wrote: >>>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>>> Full_Name: Jonathan Clarke >>>>> Version: RE24 >>>>> OS: >>>>> URL: >>>>> = > ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>>> Submission from: (NULL) (82.67.204.30) >>>>> =20 >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = > that >>>>> intercepts successful binds and records the current timestamp in an >>>>> attribute >>>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>>> is to detect >>>>> unused accounts. >>>>> =20 >>>>> A configuration parameter (olcLastBindPrecision) allows to set a = > minimum >>>>> precision for the timestamp (ie, don't update the timestamp unless >>>>> it's older >>>>> than<n> seconds). This avoids a performance hit from many >>>>> unnecessary writes in >>>>> case there are many binds per minute/hour/day/week/etc. >>>>> =20 >>>>> Of course, the behaviour this overlay implements is not described = > in >>>>> any RFC, or >>>>> other. However, it closely resembles some of the functionality from >>>>> the password >>>>> policy overlay, and similar functionality already exists in other >>>>> LDAP servers. >>> =20 >>> There is an equivalent attribute defined in the latest ppolicy draft. >>> Perhaps you could use that. > > That attribute is last successful password authentication, not last = > authentication by any means. > > For the latter, I suggest a separate attribute. At Isode, we use an = > authTimestamp dsaOperational attribute for this. > > It's wise to have the updating of this attribute off by default. Good point. In that case it's probably fine as a separate overlay, the way it is now. Can we use the schema definition that Isode is using? -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > On 10/12/10 17:14, Howard Chu wrote: >> jonathan(a)phillipoux.net wrote: >>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>> Full_Name: Jonathan Clarke >>>> Version: RE24 >>>> OS: >>>> URL: >>>> = ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>> Submission from: (NULL) (82.67.204.30) >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = that >>>> intercepts successful binds and records the current timestamp in an >>>> attribute >>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>> is to detect >>>> unused accounts. >>>>=20 >>>> A configuration parameter (olcLastBindPrecision) allows to set a = minimum >>>> precision for the timestamp (ie, don't update the timestamp unless >>>> it's older >>>> than<n> seconds). This avoids a performance hit from many >>>> unnecessary writes in >>>> case there are many binds per minute/hour/day/week/etc. >>>>=20 >>>> Of course, the behaviour this overlay implements is not described = in >>>> any RFC, or >>>> other. However, it closely resembles some of the functionality from >>>> the password >>>> policy overlay, and similar functionality already exists in other >>>> LDAP servers. >>=20 >> There is an equivalent attribute defined in the latest ppolicy draft. >> Perhaps you could use that. That attribute is last successful password authentication, not last = authentication by any means. For the latter, I suggest a separate attribute. At Isode, we use an = authTimestamp dsaOperational attribute for this. It's wise to have the updating of this attribute off by default. >> Or just submit a patch to incorporate this >> feature into the current ppoloicy overlay. >=20 > Indeed. At the time I wrote this overlay, I think the ppolicy draft = was > not yet finished or at least I wasn't aware of it. My client at the = time > found it useful to just add this simple overlay, without worrying = about > configuring ppolicy. >=20 > Since then, I actually haven't had any time to work on this overlay, = but > today Michael expressed an interest in it, asking for a public IPR > notice, thus the "thread revival". >=20 > I hope to pick it up in the future, and at that point possibly submit = a > patch for ppolicy also, as you suggest. >=20 > Regards, > Jonathan >=20 >=20

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 17:14, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>> Full_Name: Jonathan Clarke >>> Version: RE24 >>> OS: >>> URL: >>> ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>> Submission from: (NULL) (82.67.204.30) >>> >>> >>> Hi, >>> >>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >>> intercepts successful binds and records the current timestamp in an >>> attribute >>> named "bindTimestamp" in the bound-to entry. It's original use-case >>> is to detect >>> unused accounts. >>> >>> A configuration parameter (olcLastBindPrecision) allows to set a minimum >>> precision for the timestamp (ie, don't update the timestamp unless >>> it's older >>> than<n> seconds). This avoids a performance hit from many >>> unnecessary writes in >>> case there are many binds per minute/hour/day/week/etc. >>> >>> Of course, the behaviour this overlay implements is not described in >>> any RFC, or >>> other. However, it closely resembles some of the functionality from >>> the password >>> policy overlay, and similar functionality already exists in other >>> LDAP servers. > > There is an equivalent attribute defined in the latest ppolicy draft. > Perhaps you could use that. Or just submit a patch to incorporate this > feature into the current ppoloicy overlay. Indeed. At the time I wrote this overlay, I think the ppolicy draft was not yet finished or at least I wasn't aware of it. My client at the time found it useful to just add this simple overlay, without worrying about configuring ppolicy. Since then, I actually haven't had any time to work on this overlay, but today Michael expressed an interest in it, asking for a public IPR notice, thus the "thread revival". I hope to pick it up in the future, and at that point possibly submit a patch for ppolicy also, as you suggest. Regards, Jonathan

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2010