openldap-bugs

openldap-bugs@openldap.org

1 participants
21046 discussions

Re: (ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 14 Jan '09

14 Jan '09

--On Tuesday, January 13, 2009 6:25 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, January 13, 2009 9:04 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > Actually, this appears to be a kernel/epoll bug. Adding a 10000 > microsecond (.01 second) sleep to my script makes it so that slapd never > times out accepting connections. If I remove the sleep, slapd stops > accepting connections for about a 5-10 second period of time. It appears > entirely related to "connection lost" type of connections, because adding > an unbind statement also never triggers the issue. As a side note, however, LDAPI was unsable after about 200 connections with this script until the connection handling was patched. After that, it worked without any sleep in place. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 14 Jan '09

14 Jan '09

--On Tuesday, January 13, 2009 9:04 PM +0000 openldap-its(a)OpenLDAP.org wrote: Actually, this appears to be a kernel/epoll bug. Adding a 10000 microsecond (.01 second) sleep to my script makes it so that slapd never times out accepting connections. If I remove the sleep, slapd stops accepting connections for about a 5-10 second period of time. It appears entirely related to "connection lost" type of connections, because adding an unbind statement also never triggers the issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5886) epoll issues with lost connections
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When OpenLDAP is built on a system with epoll instead of select, it loses the ability to properly clean up those connections, as for epoll this is a separate event. slapd needs to be fixed to handle this case when epoll is used. It's fairly trivial to trigger it, simply write a script that does lots of searches and closes the connection without unbinding. This will cause slapd to eventually hang and stop accepting connections for a few seconds.

1 0

Re: (ITS#5885) TLS/SSL error from client
by quanah＠zimbra.com 13 Jan '09

13 Jan '09

--On Monday, January 12, 2009 5:54 PM +0000 bejnet(a)yahoo.com wrote: > 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. Usage questions should be sent to the openldap-software(a)openldap.org list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

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