openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

ITS#7008
by masarati＠aero.polimi.it 17 Aug '11

17 Aug '11

I confirm that the issue is related to performing the operation with a privileged identity, which results in pooled connections taken nearly randomly regardless of the client's connection requesting paged results. p.

1 0

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

17 Aug '11

> Full_Name: > Version: 2.4.26 > OS: > URL: > Submission from: (NULL) (84.128.254.201) > > > slapo-ppolicy(5) says: > > pwdAllowUserChange > > This attribute specifies whether users are allowed to change > their own passwords or not. If pwdAllowUserChange is set to > "TRUE", or if the attribute is not present, users will be > allowed to change their own passwords. If its value is > "FALSE", users will not be allowed to change their own pass- > words. > > Given this text I'd expect that admins can still set the userPassword > attribute. > Such a policy is often used for system/machine accounts where the machine > entity > itself does not have to change the password but an admin should be allowed > to do > so. By reading the code, I note that pwdAllowUserChange is not checked when the operation is performed by the rootdn, which in many senses can be seen as an administrator. If by administrator you mean a generic user that is logically granted administrative privileges (e.g. limited to this purpose) I concur it is not possible currently. By reading the man page (and the draft), this attribute seems to be essentially intended as a replacement (a workaround for the absence) of access control. So you could avoid setting it, and use ACLs instead. 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. p.

1 0

Re: (ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by Kurt＠OpenLDAP.org 17 Aug '11

17 Aug '11

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

ITS#7016
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

Fixed in master, please test. Now it should work correctly also in case the LDIF that is bootstrapped actually contains dn: olcDatabase=frontend,cn=config instead of dn: olcDatabase={-1}frontend,cn=config p.

1 0

RE: ITS#7020
by masarati＠aero.polimi.it 16 Aug '11

16 Aug '11

> Could you help me to transfer this question to your openldap-technical > mailing list. All you need to do is: - subscribe to the list - post the message to the list's address Instructions here <http://www.openldap.org/lists/mm/listinfo/openldap-technical>. p.

1 0

(ITS#7022) Patch - Mozilla NSS - NSS_Init* functions are not thread safe
by rmeggins＠redhat.com 16 Aug '11

16 Aug '11

Full_Name: Rich Megginson Version: current tip of master branch OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-NSS_Init-functions-are-not-thread-safe… Submission from: (NULL) (76.26.104.137) The NSS_InitContext et. al, and their corresponding shutdown functions, are not thread safe. There can only be one thread at a time calling these functions. Protect the calls with a mutex. Create the mutex using a PR_CallOnce to ensure that the mutex is only created once and not used before created. Move the registration of the nss shutdown callback to also use a PR_CallOnce. Removed the call to SSL_ClearSessionCache() because it is always called at shutdown, and we must not call it more than once. These patch files are 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.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

hyc(a)symas.com wrote: > You seem to forget that nobody has any obligation to help you, at all. You're > imposing on the generosity of volunteers. And you seem to forget that my testing and filing ITS is also voluntary work. Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > Howard Chu wrote: >> Of course, you've also been around the Project for pretty much its entire >> existence, and ought to know by now what information is needed in a useful bug >> report. > > I didn't expect having to provide a complete working setup for each small > issue. MMR setup with slapo-accesslog attached to each provider already says > it all. I also didn't expect to read non-sense about the accesslog DB itself > being replicated (see follow-up 1). > > Demanding more and more information for almost trivial things pretty much > reminds me of bad support for commercial products. You seem to forget that nobody has any obligation to help you, at all. You're imposing on the generosity of volunteers. If you're just going to complain about the response you get, as opposed to trying to help other people help you, then you should not be surprised if no help materializes. I even agree with you that follow-up #1 is nonsense. S#1t happens. Would you prefer that we moderate/censor all replies before they get posted? What exactly is it that you believe you're entitled to? > Now we'll see if this ITS will ever turn out something useful... With an attitude like that, why should anybody even take the time? > Ciao, Michael. -- -- 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#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 16 Aug '11

16 Aug '11

Howard Chu wrote: > Of course, you've also been around the Project for pretty much its entire > existence, and ought to know by now what information is needed in a useful bug > report. I didn't expect having to provide a complete working setup for each small issue. MMR setup with slapo-accesslog attached to each provider already says it all. I also didn't expect to read non-sense about the accesslog DB itself being replicated (see follow-up 1). Demanding more and more information for almost trivial things pretty much reminds me of bad support for commercial products. Now we'll see if this ITS will ever turn out something useful... Ciao, Michael.

1 0

Re: (ITS#7019) attribute auditContext should not get replicated
by hyc＠symas.com 16 Aug '11

16 Aug '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Hm, I take this back. slapd/result.c already filters out DSA-specific opattrs >> on the provider side, when the Syncrepl control is present. Something else is >> going on here, but since you failed to provide any config info there's no way >> to tell where the problem is. > > Ah nice language, "you failed" boils down to "you suck". If you want to read that into it, that's your problem. Of course, you've also been around the Project for pretty much its entire existence, and ought to know by now what information is needed in a useful bug report. If, knowing what you know, you still choose not to file useful bug reports, that's also your problem. > Anyway: http://www.stroeder.com/temp/openldap-testbed-RE24-mmr.tar.gz > > 0. Obviously you have to edit paths... > 1. Load schulung-initial-1.ldif to one of the providers. > 2. Modiy entry ou=schulung,dc=stroeder,dc=local. > > => > > dn: ou=schulung,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > auditContext: cn=accesslog,dc=stroeder,dc=local > [..] > > Tried this several times... > -- -- 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

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