openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: ITS#3515 ACLs enhancements
by ando＠sys-net.it 15 Dec '07

15 Dec '07

hyc(a)symas.com wrote: > This looks mostly like ACI to me, with some special inheritance rules. Is it > still relevant? AFAIR that was a custom ACL checking development that I found interesting from a technical point of view but (I might be wrong) of limited usefulness outside the scope it was developed for. In the meanwhile, and probably triggered by that posting, I added several ways of customizing access checking: via overlays, using dynacl (that was added earlier, for the purpose of isolating ACIs, but it could have served the same purpose). In this sense, I don't think this contribution can be of any use right now; it coulr be turned into a dynacl for custom use by the posters, or by anyone who find it useful. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

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

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