openldap-bugs December 2007

openldap-bugs@openldap.org

45 participants
166 discussions

Re: ITS#4987 slapo-constraint improvement
by hyc＠symas.com 14 Dec '07

14 Dec '07

hyc(a)symas.com wrote: > In reviewing the patch, I see several small details that need to be fixed. > E.g., you added a config keyword but re-used an existing OID for your new > attribute. OIDs must never be re-used, and certainly you must not use two > different attributes with the same OID. Oh never mind, I see the confusion. You're just defining a new 2nd argument to the existing keyword. > You use strlen/strncat, which are heavily discouraged in our code. (We never > use strcat/strncat; we use strlen only when it's unavoidable.) (Some uses of > strlen already existed in constraint.c; we just didn't get around to > eliminating them.) In general we use bervals instead of flat strings, and > there's almost never a reason to count string lengths at runtime. > > I got 3 rejects when applying the patch to my source tree (current HEAD). > > I think these points can all be cleaned up pretty easily. Let me know if you > need any particular pointers. I'm working on getting this to build 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

ITS#4987 slapo-constraint improvement
by hyc＠symas.com 14 Dec '07

14 Dec '07

In reviewing the patch, I see several small details that need to be fixed. E.g., you added a config keyword but re-used an existing OID for your new attribute. OIDs must never be re-used, and certainly you must not use two different attributes with the same OID. You use strlen/strncat, which are heavily discouraged in our code. (We never use strcat/strncat; we use strlen only when it's unavoidable.) (Some uses of strlen already existed in constraint.c; we just didn't get around to eliminating them.) In general we use bervals instead of flat strings, and there's almost never a reason to count string lengths at runtime. I got 3 rejects when applying the patch to my source tree (current HEAD). I think these points can all be cleaned up pretty easily. Let me know if you need any particular pointers. -- -- 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#4366 userPassword compare
by hyc＠symas.com 14 Dec '07

14 Dec '07

I think this is in general a bad idea. It's already noted as such in the README, which is fine. The code generally looks pretty good, although it would need to be updated for cn=config support. Does anyone else see a reason to integrate this and get it working with cn=config? -- -- 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#3515 ACLs enhancements
by hyc＠symas.com 14 Dec '07

14 Dec '07

This looks mostly like ACI to me, with some special inheritance rules. Is it still relevant? -- -- 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#5285) password policy checks userPassword hash even without policies
by mbackes＠symas.com 14 Dec '07

14 Dec '07

Full_Name: Matthew Backes Version: 2.3, 2.4, head, etc OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.115.65.234) When receiving a new userPassword, slapo-ppolicy checks to see if that password matches the hash already present in userPassword, and disallows it if this is the case. This is a sensible default for most circumstances, as otherwise the user could reset their age counters by using the same password. Unfortunately, it also blocks arguably-legitimate password changes; e.g. when migration to SSHA from CRYPT where the first 8 chars of the new password match the old. This patch changes this userPassword-has-changed check to only apply if there is a password policy defined which requires it; in particular, any of pwdInHistory, pwdMinAge, pwdMaxAge, pwdCheckQuality, or pwdMustChange must apply for this check to be enforced. RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.110 diff -u -r1.110 ppolicy.c --- ppolicy.c 17 Nov 2007 12:39:19 -0000 1.110 +++ ppolicy.c 15 Dec 2007 03:21:27 -0000 @@ -1776,7 +1776,13 @@ * Last check - the password history. */ /* FIXME: no access checking? */ - if (slap_passwd_check( op, NULL, pa, bv, &txt ) == LDAP_SUCCESS) { + if (( pp.pwdInHistory + || pp.pwdMinAge + || pp.pwdMaxAge + || pp.pwdCheckQuality + || pp.pwdMustChange ) /* make sure we care */ + && ( slap_passwd_check( op, NULL, pa, bv, &txt ) + == LDAP_SUCCESS )) { /* * This is bad - it means that the user is attempting * to set the password to the same as the old one.

1 0

ITS#3429 schema download module
by hyc＠symas.com 14 Dec '07

14 Dec '07

I was looking at this code in relation to current HEAD/RE24, and things have changed quite a bit. Given the ability to dynamically load schema into cn=config, is there still a need for this module? (It is in fact the changes made for dynamic schema manipulation in slapd that causes the compatibility issues with this module.) -- -- 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#4398 unique overlay enhancement
by hyc＠symas.com 14 Dec '07

14 Dec '07

Thanks for your patches. A more extensive version of these features was added in OpenLDAP 2.4 (March 2007). 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#5263) ldap_parse_sasl_bind_result() returning wrong error code
by hyc＠symas.com 14 Dec '07

14 Dec '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD, RE23, RE24 > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.205.58) > > > According to the man-pages and the C-API draft the ldap_parse_*_result() > functions return LDAP_SUCCESS, when the result was successfully parsed, > otherwise != LDAP_SUCCESS. > The current implementation of ldap_parse_sasl_bind_result() (not sure about > ldap_parse_extended_result()) however will return the LDAP Error Code of the > passwd LDAPMessages as the result (e.g. LDAP_SASL_BIND_IN_PROGRESS). > > If this is the desired behavior we should fix our documentation. But I guess > this is a bug in ldap_parse_sasl_bind_result() and probably > ldap_parse_extended_result(). Fixed in HEAD. ldap_parse_extended_result() was correct. -- -- 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#5284) cn=config overlay order
by hyc＠symas.com 14 Dec '07

14 Dec '07

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.3.39/2.4.6 > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (96.228.44.90) > > > Overlays are processed in the reverse order of slapd.conf when using slapd.d. Thanks for the report, this is now fixed in CVS HEAD. -- -- 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#5284) cn=config overlay order
by dhawes＠vt.edu 14 Dec '07

14 Dec '07

Full_Name: David Hawes Version: 2.3.39/2.4.6 OS: Debian GNU/Linux URL: Submission from: (NULL) (96.228.44.90) Overlays are processed in the reverse order of slapd.conf when using slapd.d. If I have the following in slapd.conf: ... overlay overlay1 overlay overlay2 overlay overlay3 ... and convert it to slapd.d, I will see the following in cn=config: ... # {0}overlay3, {1}bdb, config dn: olcOverlay={0}overlay3,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}overlay3 # {1}overlay2, {1}bdb, config dn: olcOverlay={1}overlay2,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}overlay2 # {2}overlay1, {1}bdb, config dn: olcOverlay={2}overlay1,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {2}overlay1 ... When slapd is started with slapd.conf, the overlay stack is correct (overlay3 -> overlay2 -> overlay1 for processing order), although cn=config reports the above. When slapd.d is used, the overlay stack is the opposite (overlay1 -> overlay2 -> overlay3). This occurs in both 2.3.39 and 2.4.6. I see this as a problem in situations where order of overlays is important (syncprov comes to mind).

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2007