openldap-bugs August 2011

openldap-bugs@openldap.org

29 participants
100 discussions

Re: (ITS#6993) Backend Connection problem
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> Full_Name: Yann Carre > Version: 2.4.26 > OS: red hat 5 (64 bits) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.208.49.20) > > > I work on a specific Backend > I have provided in my back end a function to the bi_connection_init > pointer. > This function adds a context needed in the operation backend function > (search, > ...) > > When several connections start up, my LDAP server crashes. > The crash arrives because the context is not created before the call to > do_searh. > The connection is provided to the application Backend before my Back end > connection_init. > I have checked it with the debugger and see that the thread with > initialize the > connection is suspend before the backend connection_init. In another > thread, the > search function is executed without any context attached to the > connection. > > This problem seems to be bring because the connection mutex is freed > before the > calling of the Back end connection_init in the function connection_init > (connection.c). > > I have moved this mutex after the backend connection_init and it seems to > work. > > Would you confirm this analysis and take the correction in account? Honestly, if that context you mention is connection-specific, I don't see how this could happen, since operations on that connection should not be possible until connection_init() returns. OTOH, if the context is global, you should initialize it differently, and protect it from being used before its initialization is complete, e.g. by a specific mutex that is completely internal to your backend. In any case, it is not clear how this can be an OpenLDAP bug. You should provide a clearer evidence. In the absence, I'd consider this ITS closed. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> masarati(a)aero.polimi.it wrote: >> The patch is the result of my reading in 5 minutes a single portion of a >> spec I read in detail years ago, so my interpretation could not be the >> most correct. > > But your interpretation makes sense: E.g. system accounts most times do > not > need to change their own password. And for security reasons you might want > to > avoid that. Think of a the case where the password of a more exposed > system is > known by an attacker (which is likely a very bad case anyway). But at > least > the attacker should not be able to disable this service by setting a new > password. > > Yes, this can be done with ACLs. But you might already have a password > policy > assigned to this special system accounts because you don't want the system > accounts' password to expire. So adding an extra ACL is more work > especially > if system accounts are spread across a more complicated DIT. Well, as a counter-example, if security is compromised, then setting pwdAllowUserChange to FALSE would only prevent password modification for users that fall under that password policy, while others would need to be protected anyway using ACLs. And if security is seriously compromised, none of these would work, because rootdn circumvents all checks. So giving different orthogonal means to obtain similar but not identical effects sounds to me making things more complicated than they ought to be. Given the fact that pwdAllowUserChange is a gross subset of ACLs, I'd rather discourage its usage through clear documentation than try to make it conform to some or some other interpretation of the specs. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 18 Aug '11

18 Aug '11

masarati(a)aero.polimi.it wrote: > The patch is the result of my reading in 5 minutes a single portion of a > spec I read in detail years ago, so my interpretation could not be the > most correct. But your interpretation makes sense: E.g. system accounts most times do not need to change their own password. And for security reasons you might want to avoid that. Think of a the case where the password of a more exposed system is known by an attacker (which is likely a very bad case anyway). But at least the attacker should not be able to disable this service by setting a new password. Yes, this can be done with ACLs. But you might already have a password policy assigned to this special system accounts because you don't want the system accounts' password to expire. So adding an extra ACL is more work especially if system accounts are spread across a more complicated DIT. Ciao, Michael.

1 0

(ITS#7023) TLSCACertificateFile description in slapd.conf.5 is missing critical information
by Frank.Swasey＠uvm.edu 18 Aug '11

18 Aug '11

Full_Name: Francis Swasey Version: 2.4.26 OS: Linux URL: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.… Submission from: (NULL) (132.198.107.64) The following referenced patch copies critical information that should be in the slapd.conf.5 man page from the admin guide: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.…

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 18 Aug '11

18 Aug '11

> masarati(a)aero.polimi.it wrote: >>>> Then the patch is trivial: >>>> [..] >>>> If there's consensus, I'll commit it. >>> >>> Seems like a pointless change. You must set ACLs for this type of >>> modification >>> to be allowed. Since you must set ACLs anyway, there is no good reason >>> to >>> use >>> the pwdAllowUserChange policy setting in the first place. In general >>> the >>> pwdAllowUserChange option is only useful on systems that do not already >>> provide fine grained access controls. >> >> Agree (see my previous message). For this purpose, I suggest to add, in >> slapo-ppolicy(5), a comment about discouraging the use of >> pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. > > I already knew that this can be achieved by ACLs but... > > 1. OpenLDAP should behave as stated in the ppolicy spec and the man-pages. > > 2. sometimes it'd be more handy to use this flag in an already existing > pwdPolicy entry than defining additional ACLs. > > Since this patch seems so trivial why not commit it? The patch is the result of my reading in 5 minutes a single portion of a spec I read in detail years ago, so my interpretation could not be the most correct. Since Howard implemented slapo-ppolicy(5), I believe his interpretation of the spec is more accurate. The fact that he interprets this flag as a complete replacement of ACLs on systems where they are not granular enough lets me think that its behavior should be broader (i.e. apply to all users) rather than strictly sticking to the word (i.e. apply to self only). That's why I'm seeking consensus before committing a patch (that could be harmful, as the current behavior of slapo-ppolicy(5) makes this flag work as a complete alternative to ACLs, while the new behavior, not complemented by appropriate ACLs, could allow anybody but self to change the pwd). p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 18 Aug '11

18 Aug '11

masarati(a)aero.polimi.it wrote: >>> Then the patch is trivial: >>> [..] >>> If there's consensus, I'll commit it. >> >> Seems like a pointless change. You must set ACLs for this type of >> modification >> to be allowed. Since you must set ACLs anyway, there is no good reason to >> use >> the pwdAllowUserChange policy setting in the first place. In general the >> pwdAllowUserChange option is only useful on systems that do not already >> provide fine grained access controls. > > Agree (see my previous message). For this purpose, I suggest to add, in > slapo-ppolicy(5), a comment about discouraging the use of > pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. I already knew that this can be achieved by ACLs but... 1. OpenLDAP should behave as stated in the ppolicy spec and the man-pages. 2. sometimes it'd be more handy to use this flag in an already existing pwdPolicy entry than defining additional ACLs. Since this patch seems so trivial why not commit it? Ciao, Michael.

1 0

RE: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 17 Aug '11

17 Aug '11

>Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS. The contributed works provided by Joshua Tree Software, LLC. and referenced in this ITS were created by Joshua Tree Software, LLC., who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. Shawn McKinney -------- Original Message -------- Subject: Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> Date: Wed, August 17, 2011 10:19 am To: "<shawn.mckinney(a)jtstools.com>" <shawn.mckinney(a)jtstools.com> Cc: openldap-its(a)OpenLDAP.org On Aug 15, 2011, at 7:15 PM, <shawn.mckinney(a)jtstools.com> <shawn.mckinney(a)jtstools.com> wrote: > The product named "Fortress Core" includes contributions that were created by JoshuaTree Software, LLC, who is the exclusive owner of the works. This contribution is made available as indicated by the copyright and license statements attached to the the work. Shawn, the wording of this statement is not sufficient clear for a couple of reasons. One, the term product doesn't necessarily refer to the contributed works. Two, "includes" language doesn't exclude the possibility that portions of the contributed work were created by others. We need the statement of origin to be quite clear. Assuming all of the contributed works were created by JohshuaTree Software, LLC, we suggest stating something of the form. The contributed works provided by <creator> and referenced in this ITS were created by <creator>, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. where <creator> was replaced with JoshuaTree Software, LLC. Please restate the statement of origin, either in the above form or other appropriate form, in response to this ITS. Regards, Kurt > > Shawn McKinney > -------- Original Message -------- > Subject: Re: (ITS#6995) Request for Contribution of Identity Access > Management Software to OpenLDAP Project > From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> > Date: Mon, August 15, 2011 2:35 pm > To: shawn.mckinney(a)jtstools.com > Cc: openldap-its(a)OpenLDAP.org > > Shawn, > > I have reviewed the submitted materials. > > Other than a lack of a statement of origin, I find no reason why these materials cannot be accepted. Please submit a "statement of origin" in a follow-up to this ITS. This can simply be a statement to the effect that the all the submitted materials were authored by JoshuaTree Software, JoshaaTree is the exclusive owner of the works, and that the contribution is made available as indicated by the copyright and license statements in the work. If the work includes materials derived from works to which others own or otherwise have rights to, please detail. > > The Foundation has no objection to the Project establishing a sub-project of the OpenLDAP Project, similar to the Java LDAP and JDBC-LDAP sub projects, to develop works based upon your contribution. It is the Foundation understanding that Project is also willing to establish such a sub-project, and extend commit privs to the key developers who produced the contributed work. > > It is noted that the OpenLDAP Foundation, if it accepts the final contribution, would from time to time publish works derived (such as the source repository itself, and possibly packaged source bundles) from your contribution as well as possibly the contributions of others. The OpenLDAP Foundation will license its copyright right interests (initially likely quite limited) using the OpenLDAP Public License, and will encourage community members to license their contributions in a manner consistent with our general contribution guidelines. The OpenLDAP Public License is compatible with the 'New BSD open source license' and similar in its basic terms. > > The initial COPYRIGHT file (upon acceptance and initial publication by the OpenLDAP Foundation) would be based on the COPYRIGHT file currently found in OpenLDAP Software distributions, excepting JoshuaTree Software would be named as the contributor of the materials for which the published work is derived from, and notice immediately following the Foundation's notice would be that provided by JoshauTree covering the work as contributions. > > It is noted that I recently attempted to re-download the materials and they were no longer available. That fine, we'd want you to upload fresh zips to our servers once we all were ready to proceed. > > Regards, Kurt > > On Jul 14, 2011, at 6:51 PM, shawn.mckinney(a)jtstools.com wrote: > > > Full_Name: Shawn McKinney > > Version: All > > OS: All > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (99.34.198.251) > > > > > > Hello, > > > > We have created a new Identity and Access Management SDK, called Fortress, that > > uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password > > policies, auditing and more. > > > > It has taken us 2.5 years of steady work to get it ready for this 1.0 release. > > This SDK has approximately 50K lines of Java code of which approximately 25K are > > dedicated to testing using JUnit automated tests to ensure it works correctly. > > There are in excess of 100 public APIs available for use. There is also a Java > > EE container plug-in that provides authentication and authorization services to > > Websphere, Tomcat and JBoss app servers in a declarative fashion. > > > > This product has not been published and we would like to release it as one of > > the products under OpenLDAP family of products. The product will be released > > under New BSD open source license (license information is contained in the > > source archives on ftp server). > > > > I have uploaded seven packages to our FTP server that contain the source, > > documentation and other items for you to look at. > > > > host: jtstools.com > > user: jtsguest1 > > pw: OpenLd@p1 > > > > The packages are as follows: > > > > Fortress Core SDK > > > > 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes > > 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes > > 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes > > 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes > > 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf > > > > > > Fortress Realm (Java EE Container plug-ins) > > > > 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes > > 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes > > > > > > Package 4 contains complete javadoc for the APIs. > > > > In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the > > overall summary of the SDK. > > > > this link, ./oamCore/trunk/dist/docs/api/index.html, contains package > > descriptions along with detailed documentation describing the contents of the > > SDK. > > > > What we are requesting from the OpenLDAP foundation: > > > > 1. Source code repository to host the SDK and Realm packages. > > 2. Bug tracking. > > 3. Developer and User forums. > > 4. Wiki (this is a nice to have) > > > > Our goal is to run the open source project with your organization and cultivate > > a healthy developer and user community. We have high hopes for this product > > (and OpenLDAP) and consider the 2 products together as an open source > > alternative for IAM products that will compete with the commercial vendor > > offerings. > > > > Once 1.0 is released, we will begin working on 2.0 which will include UI's to > > control Fortress and OpenLDAP along with a policy server to wrap the Fortress > > Java APIs with HTTP/REST Web APIs to make it available to all platforms. > > > > Thanks in advance for your consideration. > > > > Shawn McKinney > > JoshuaTree Software > > shawn.mckinney(a)jtstools.com > > >

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

> masarati(a)aero.polimi.it wrote: >>> masarati(a)aero.polimi.it wrote: >>>> OTOH, by strictly interpreting the way its use is discussed in the >>>> draft, >>>> it should only apply to attempts by "self" to modify the password, so >>>> a >>>> modification performed by a different identity (provided ACLs permit >>>> it) >>>> should not be affected. >>> >>> Yes, that's my understanding too. >> >> Then the patch is trivial: >> >> diff --git a/servers/slapd/overlays/ppolicy.c >> b/servers/slapd/overlays/ppolicy.c >> index 6a693ac..d9afac9 100644 >> --- a/servers/slapd/overlays/ppolicy.c >> +++ b/servers/slapd/overlays/ppolicy.c >> @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) >> >> if (be_isroot( op )) goto do_modify; >> >> - if (!pp.pwdAllowUserChange) { >> + /* NOTE: according to draft-behera-ldap-password-policy >> + * pwdAllowUserChange == FALSE only prevents pwd changes >> + * by the user the pwd belongs to (ITS#7021) */ >> + if (!pp.pwdAllowUserChange&& >> dn_match(&op->o_req_ndn,&op->o_ndn)) { >> rs->sr_err = LDAP_INSUFFICIENT_ACCESS; >> rs->sr_text = "User alteration of password is not >> allowed"; >> pErr = PP_passwordModNotAllowed; >> >> If there's consensus, I'll commit it. > > Seems like a pointless change. You must set ACLs for this type of > modification > to be allowed. Since you must set ACLs anyway, there is no good reason to > use > the pwdAllowUserChange policy setting in the first place. In general the > pwdAllowUserChange option is only useful on systems that do not already > provide fine grained access controls. Agree (see my previous message). For this purpose, I suggest to add, in slapo-ppolicy(5), a comment about discouraging the use of pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by hyc＠symas.com 17 Aug '11

17 Aug '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>> OTOH, by strictly interpreting the way its use is discussed in the >>> draft, >>> it should only apply to attempts by "self" to modify the password, so a >>> modification performed by a different identity (provided ACLs permit it) >>> should not be affected. >> >> Yes, that's my understanding too. > > Then the patch is trivial: > > diff --git a/servers/slapd/overlays/ppolicy.c > b/servers/slapd/overlays/ppolicy.c > index 6a693ac..d9afac9 100644 > --- a/servers/slapd/overlays/ppolicy.c > +++ b/servers/slapd/overlays/ppolicy.c > @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) > > if (be_isroot( op )) goto do_modify; > > - if (!pp.pwdAllowUserChange) { > + /* NOTE: according to draft-behera-ldap-password-policy > + * pwdAllowUserChange == FALSE only prevents pwd changes > + * by the user the pwd belongs to (ITS#7021) */ > + if (!pp.pwdAllowUserChange&& dn_match(&op->o_req_ndn,&op->o_ndn)) { > rs->sr_err = LDAP_INSUFFICIENT_ACCESS; > rs->sr_text = "User alteration of password is not allowed"; > pErr = PP_passwordModNotAllowed; > > If there's consensus, I'll commit it. Seems like a pointless change. You must set ACLs for this type of modification to be allowed. Since you must set ACLs anyway, there is no good reason to use the pwdAllowUserChange policy setting in the first place. In general the pwdAllowUserChange option is only useful on systems that do not already provide fine grained access controls. -- -- 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#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

> masarati(a)aero.polimi.it wrote: >> OTOH, by strictly interpreting the way its use is discussed in the >> draft, >> it should only apply to attempts by "self" to modify the password, so a >> modification performed by a different identity (provided ACLs permit it) >> should not be affected. > > Yes, that's my understanding too. Then the patch is trivial: diff --git a/servers/slapd/overlays/ppolicy.c b/servers/slapd/overlays/ppolicy.c index 6a693ac..d9afac9 100644 --- a/servers/slapd/overlays/ppolicy.c +++ b/servers/slapd/overlays/ppolicy.c @@ -1792,7 +1792,10 @@ ppolicy_modify( Operation *op, SlapReply *rs ) if (be_isroot( op )) goto do_modify; - if (!pp.pwdAllowUserChange) { + /* NOTE: according to draft-behera-ldap-password-policy + * pwdAllowUserChange == FALSE only prevents pwd changes + * by the user the pwd belongs to (ITS#7021) */ + if (!pp.pwdAllowUserChange && dn_match(&op->o_req_ndn, &op->o_ndn)) { rs->sr_err = LDAP_INSUFFICIENT_ACCESS; rs->sr_text = "User alteration of password is not allowed"; pErr = PP_passwordModNotAllowed; If there's consensus, I'll commit it. p.

1 0

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2011