openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by andrew.findlay＠skills-1st.co.uk 13 Jan '09

13 Jan '09

On Mon, Jan 12, 2009 at 07:47:20PM +0000, hyc(a)symas.com wrote: > > For example, if I have a DIT like this: > > > > dc=example,dc=org--+ > > +--dc=a--+ > > | +--dc=people--+ > > | +--cn=a1 > > | > > +--dc=b--+ > > +--dc=people--+ > > +--cn=b1 > > > > and I give read access on dc=example,dc=org (base) > > and on dc=a,dc=example,dc=org (subtree) > > and dc=people,dc=b,dc=example,dc=org (subtree) > > but no access at all on dc=b,dc=example,dc=org > > then I would not expect to be able to read the cn=b1 entry, as doing so would > > expose the existence of dc=b. > > > > What actually happens is that any attempt to read dc=b itself returns > > correctly as if the entry does not exist, but a simple subtree search > > happily returns cn=b1. > > Which is the natural outcome of granting read access to the dc=people subtree. > > If you want the server's behavior to make sense, then give it ACLs that make > sense. Agreed - for some value of "sense" :-) I simplified the example to the minimum that would demonstrate the behaviour, so it may seem like an odd thing to do in the first place. There are several possible reasons to want a non-discoverable entry to block discovery of entries beneath it. One example would be an organisation that is preparing to open a new department: it needs to populate the department data with entries carrying the access markers that will be used in production, but have the whole lot remain invisible to users and applications until everything is ready. The obvious way to implement this is to use access-control to make the root of the new subtree non-discoverable, but it only works if the non-discoverability extends to the whole subtree. This is effectively the scenario that I described in the ITS. I want to make the discoverability of entries dependent on the value of an attribute in a parent node, but I cannot see a way of doing it using the existing ACL syntax and behaviour. The closest I have got so far is to use the set syntax in a deny rule: # Blockers - look for exampleVisibility=block in all parent entries # access to * by set="this/-*/exampleVisibility & [block]" none by * break This allows any entry to block its subtree to *all* users by setting exampleVisibility=block There does not seem to be any way to make the block dependent on *who* is requesting access, as sets are only valid in the 'by <who>' part of the rule. Something like this might work if sets could be used in the <what> part: access to set="this/-*/exampleVisibility & [internet]" attrs="entry,children" by * read access to set="this/-*/exampleVisibility & [users]" attrs="entry,children" by users read Ah - no it would not work, as it would permit read if *any* superior entry permits read. I want to be sure that *all* superior entries permit read. Foiled again! Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5884) disclose ACL not safe on non-leaf objects
by hyc＠symas.com 12 Jan '09

12 Jan '09

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: HEAD 12 Jan 2009 > OS: Linux > URL: > Submission from: (NULL) (88.97.25.132) > > > Using ACLs to make a non-leaf object non-disclosable does not protect > the subtree beneath that object. > > This is not what most people would expect (if I cannot see a given object > then I would not expect to see things underneath it). It also provides > a handy attack on supposedly non-detectable entries. > > For example, if I have a DIT like this: > > dc=example,dc=org--+ > +--dc=a--+ > | +--dc=people--+ > | +--cn=a1 > | > +--dc=b--+ > +--dc=people--+ > +--cn=b1 > > and I give read access on dc=example,dc=org (base) > and on dc=a,dc=example,dc=org (subtree) > and dc=people,dc=b,dc=example,dc=org (subtree) > but no access at all on dc=b,dc=example,dc=org > then I would not expect to be able to read the cn=b1 entry, as doing so would > expose the existence of dc=b. > > What actually happens is that any attempt to read dc=b itself returns > correctly as if the entry does not exist, but a simple subtree search > happily returns cn=b1. Which is the natural outcome of granting read access to the dc=people subtree. If you want the server's behavior to make sense, then give it ACLs that make sense. -- -- 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

(ITS#5885) TLS/SSL error from client
by bejnet＠yahoo.com 12 Jan '09

12 Jan '09

Full_Name: Bejoy Version: 2.4.11 OS: gNewSense Gnu/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.211.200.129) Hi I am having some TLS/SSL issues for connecting with ldapsearch from clients. While using openssl to check the certificates - the OpenLDAP server responds properly. But when ldapsearch uses the same certificates, server throws error on improper TLS handshake.

1 0

(ITS#5884) disclose ACL not safe on non-leaf objects
by andrew.findlay＠skills-1st.co.uk 12 Jan '09

12 Jan '09

Full_Name: Andrew Findlay Version: HEAD 12 Jan 2009 OS: Linux URL: Submission from: (NULL) (88.97.25.132) Using ACLs to make a non-leaf object non-disclosable does not protect the subtree beneath that object. This is not what most people would expect (if I cannot see a given object then I would not expect to see things underneath it). It also provides a handy attack on supposedly non-detectable entries. For example, if I have a DIT like this: dc=example,dc=org--+ +--dc=a--+ | +--dc=people--+ | +--cn=a1 | +--dc=b--+ +--dc=people--+ +--cn=b1 and I give read access on dc=example,dc=org (base) and on dc=a,dc=example,dc=org (subtree) and dc=people,dc=b,dc=example,dc=org (subtree) but no access at all on dc=b,dc=example,dc=org then I would not expect to be able to read the cn=b1 entry, as doing so would expose the existence of dc=b. What actually happens is that any attempt to read dc=b itself returns correctly as if the entry does not exist, but a simple subtree search happily returns cn=b1. The workaround is to make every entry in the dc=b subtree non-disclosable, but this can be awkward in some ACL schemes. I have tested this with both BDB and HDB and got identical results. (I also tried to do it with IBM's ITDS and Sun's DSEE but they don't even support the non-disclose concept...) There is no RFC for LDAP ACLs so the 'correct' behaviour is debatable... Here are the files: --------------------------------- slapd.conf --------------------------------- # Logging - this goes to syslog as 'local4' # # 512+256 to enable stats logging # loglevel 768 # Schema definitions # include ../../etc/schema/core.schema include ../../etc/schema/cosine.schema include ../../etc/schema/inetorgperson.schema include ../../etc/schema/nis.schema # These should have absolute pathnames on production systems pidfile ./slapd.pid argsfile ./slapd.args ######################################################################## # Default ACL # (This is overridden by the per-database ACLs) ######################################################################## access to * by * read ######################################################################## ####################################################################### # The main database ####################################################################### ######################################################################## database hdb suffix "dc=example,dc=org" rootdn "cn=root,dc=example,dc=org" password-hash {SSHA} # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # # The following two lines describe the same password: # rootpw secret # rootpw {SSHA}fFCeSYwjK/wERk1h4ceqYohqrGT/8VxJ # rootpw password # The database directory MUST exist prior to running slapd AND # should only be accessable by the slapd/tools. Mode 700 recommended. # This should be an absolute pathname on production servers. # directory ./openldap-db # Entry cache size # cachesize 4000 # How often we force a checkpoint on the underlying database # kilobytes and seconds # checkpoint 128 300 ######################################################################## # Indices to maintain ######################################################################## index objectClass eq ######################################################################## # ACLs for this database ######################################################################## include ./slapd.conf.acls ----------------------------- slapd.conf.acls ------------------------------ # Allow unconditional access to the base object # access to dn.exact="dc=example,dc=org" by * read # Allow read access to the whole of the A subtree # access to dn.subtree="dc=a,dc=example,dc=org" by * read # Allow read access to B's people, but not to B # access to dn.subtree="dc=people,dc=b,dc=example,dc=org" by * read access to * by * none ----------------------------- data LDIF ----------------------------------- ######################################################################## # Create the base object ######################################################################## # dn: dc=example,dc=org objectclass: organization objectclass: dcObject o: The Example Org dc: example description: See-under test ######################################################################## # Create departments ######################################################################## # A dn: dc=a,dc=example,dc=org objectclass: organizationalUnit objectclass: dcObject ou: Department A dc: a dn: dc=people,dc=a,dc=example,dc=org objectclass: organizationalUnit objectclass: dcObject ou: People dc: people # B dn: dc=b,dc=example,dc=org objectclass: organizationalUnit objectclass: dcObject ou: Department B dc: b dn: dc=people,dc=b,dc=example,dc=org objectclass: organizationalUnit objectclass: dcObject ou: People dc: people ######################################################################## # Create accounts ######################################################################## # dn: cn=a1,dc=people,dc=a,dc=example,dc=org objectclass: inetOrgPerson cn: a1 sn: One dn: cn=b1,dc=people,dc=b,dc=example,dc=org objectclass: inetOrgPerson cn: b1 sn: One ----------------------------- tests ----------------------------------------- # Search for dept A: this should work ldapsearch -x -H ldap://:1389/ -b dc=example,dc=org dc=a # Search for dept B: this should return zero results as B is protected by ACLs ldapsearch -x -H ldap://:1389/ -b dc=example,dc=org dc=b # Try starting at dept B: this should return 'no such object' as B is protected by ACLs ldapsearch -x -H ldap://:1389/ -b dc=b,dc=example,dc=org dc=b # Search for a user in dept A: this should work ldapsearch -x -H ldap://:1389/ -b dc=example,dc=org cn=a1 # Search for a user in dept B. # This exposes the supposedly non-detectable department B... ldapsearch -x -H ldap://:1389/ -b dc=example,dc=org cn=b1

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 12 Jan '09

12 Jan '09

Pierangelo Masarati wrote: [...] > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. any luck with this? Regards, Rob

1 0

(ITS#5883) [PATCH] syncrepl test enhancements
by richton＠nbcs.rutgers.edu 11 Jan '09

11 Jan '09

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: https://www.nbcs.rutgers.edu/~richton/syncrepl-modrdn-tests.patch Submission from: (NULL) (67.85.181.229) Per http://www.openldap.org/lists/openldap-devel/200812/msg00004.html these patches enhance tests to detect ITS#5809-like behavior. The actual test changes are at the address linked to this report. They should apply clean to HEAD and can be used immediately with, for example, back-ldif. I note that I wasn't able to reproduce a failure under test018; if anybody can suggest a different test there, that'd be great, or perhaps the stopping and starting somehow masks the condition? While verifying the tests, I noticed that some backends (such as back-bdb) were failing because the consumer and provider returned the attributes in a different order. Since attribute ordering isn't guaranteed, I viewed this as a test failure rather than a slapd failure, and used the back-ndb gawk acfilter.sh to work around this. In the end I just made it apply to all backends: https://www.nbcs.rutgers.edu/~richton/acfilter.patch but we'll probably want to discuss this on -devel: it adds a gawk dependency to the tests. With the acfilter.sh sorting enabled, I found three tests that don't filter the original data prior to ldapsearch comparison. I added these filters in: https://www.nbcs.rutgers.edu/~richton/openldap-testflt.patch We all know that nothing's free -- a couple extra commands in the name of bug coverage is probably worth it -- but the gawk dependency may be troublesome. Anyway, do what you will...I consider these pretty trivial, so: These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in these patches were developed by Aaron Richton <richton(a)nbcs.rutgers.edu>. I have not assigned rights and/or interest in this work to any party. I, Aaron Richton, hereby place these 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#5882) ldap
by ab.tamouh＠gmail.com 10 Jan '09

10 Jan '09

------=_Part_160275_12544830.1231621158447 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline tanks , about the number of version: In redhat ES 4 when i listed the installed packages of ldap ,it will return this number of version. I find the problem is in schema at slapd.conf i include the krb5-kdc.schema, so i dwonload one from internet and i start the ldap service 2009/1/9 <openldap-its(a)openldap.org> > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#5882. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#5882) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#5882) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=5882 > > Please remember to retain your issue tracking number (ITS#5882) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > ------=_Part_160275_12544830.1231621158447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr">tanks , about the number of version: In redhat ES 4 when i listed the installed packages of ldap ,it will return this number of version. I find the problem is in schema at slapd.conf i include the krb5-kdc.schema, so i dwonload one from internet and i start the ldap service <div class="gmail_quote">2009/1/9 <<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.  Your report has been assigned the tracking number ITS#5882. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.  They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.  Note that any mail sent to <a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> with (ITS#5882) in the subject will automatically be attached to the issue report.        mailto:<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>?subject=(ITS#5882) You may follow the progress of this report by loading the following URL in a web browser:    <a href="http://www.OpenLDAP.org/its/index.cgi?findid=5882" target="_blank">http://www.OpenLDAP.org/its/index.cgi?findid=5882</a> Please remember to retain your issue tracking number (ITS#5882) on any further messages you send to us regarding this report.  If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported.        <a href="http://www.OpenLDAP.org/support/" target="_blank">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> </div> ------=_Part_160275_12544830.1231621158447--

1 0

Re: (ITS#5882) ldap
by quanah＠zimbra.com 09 Jan '09

09 Jan '09

--On Friday, January 09, 2009 2:54 PM +0000 ab.tamouh(a)gmail.com wrote: > Full_Name: tamouh abd > Version: 2.2.3.18 > OS: redhat > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (41.251.2.183) 2.2.3.18 is not a valid version number. I suggest you discuss the issue you are facing on an appropriate list, such as openldap-software(a)openldap.org. What you report is not a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5882) ldap
by ab.tamouh＠gmail.com 09 Jan '09

09 Jan '09

Full_Name: tamouh abd Version: 2.2.3.18 OS: redhat URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.251.2.183) Checking configuration files for slapd: /etc/openldap/schema/krb5-kdc.schema: line 80: AttributeType inappropriate matching rule: "generalizedTimeOrderingMatch"

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 08 Jan '09

08 Jan '09

Howard Chu <hyc(a)symas.com> wrote: > > I committed the overlay in the contrib folder > As I mentioned before, you should be using a config OID from the Contrib > branch, and noting this in contrib/ConfigOIDs. Oops, sorry, I must have missed your message. I will take care of that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2009