openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5561) SEGV using TLS/SASL
by hyc＠symas.com 17 Jun '08

17 Jun '08

lea.anthony(a)meirion-dwyfor.ac.uk wrote: > Full_Name: Lea Anthony > Version: 2.3.40 > OS: Arch Linux > URL: http://pastebin.com/f6b680f22 > Submission from: (NULL) (194.82.229.100) > > > I have TLS setup as follows: > > TLSCertificateFile /etc/openldap/certs/cert.pem > TLSCertificateKeyFile /etc/openldap/certs/key.pem > TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 > > The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind > fine. > > However, doing "ldapsearch -ZZ" will cause a segfault on the server. The > pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1". I'm unable to reproduce this crash. Please provide a stack trace. http://www.openldap.org/faq/data/cache/59.html -- -- 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#5564) Use largest contextCSN to determine staleness?
by hyc＠symas.com 17 Jun '08

17 Jun '08

rein(a)OpenLDAP.org wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --8323329-1817437300-1213728437=:15378 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: > > rein(a)OpenLDAP.org wrote: > >> A fix that seems to solve this is that syncprov_findbase(FIND_CSN) >> should search for entries whose entryCSN value is less than the >> largest contextCSN presented by the client. All the test scripts >> succeed if I try this, but I'm not convinced that this is the correct >> fix. Would it not be more correct to ignore the entire CSN set >> presented by the consumer when it has been determined as stale. > > After looking a bit more on this I'm more convinced that the alternative > fix is the correct. A patch that implements this is attached, all tests > succeed with it. Howard, can you approve or comment on it? This patch looks OK to me, go ahead and commit. -- -- 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#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 17 Jun '08

17 Jun '08

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote: rein(a)OpenLDAP.org wrote: > A fix that seems to solve this is that syncprov_findbase(FIND_CSN) > should search for entries whose entryCSN value is less than the > largest contextCSN presented by the client. All the test scripts > succeed if I try this, but I'm not convinced that this is the correct > fix. Would it not be more correct to ignore the entire CSN set > presented by the consumer when it has been determined as stale. After looking a bit more on this I'm more convinced that the alternative fix is the correct. A patch that implements this is attached, all tests succeed with it. Howard, can you approve or comment on it? Rein --8323329-1817437300-1213728437=:15378 Content-Type: TEXT/x-diff; name=ITS-5564.patch Content-Transfer-Encoding: BASE64 Content-ID: <alpine.DEB.1.00.0806172047070.15378(a)monster.tollevik.no> Content-Description: Content-Disposition: attachment; filename=ITS-5564.patch SW5kZXg6IHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3luY3Byb3YuYw0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9mL0NWU1JPT1QvZHJp ZnQvT3BlbkxEQVAvc2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5j LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMA0KZGlmZiAtdSAtdSAtcjEu MzAgc3luY3Byb3YuYw0KLS0tIHNlcnZlcnMvc2xhcGQvb3ZlcmxheXMvc3lu Y3Byb3YuYwkxMyBKdW4gMjAwOCAxMzo0OTozNiAtMDAwMAkxLjMwDQorKysg c2VydmVycy9zbGFwZC9vdmVybGF5cy9zeW5jcHJvdi5jCTE3IEp1biAyMDA4 IDEzOjA3OjUxIC0wMDAwDQpAQCAtMjMyMyw2ICsyMzIzLDE1IEBADQogCQkJ CXNlbmRfbGRhcF9lcnJvciggb3AsIHJzLCBMREFQX1NZTkNfUkVGUkVTSF9S RVFVSVJFRCwgInN5bmMgY29va2llIGlzIHN0YWxlIiApOw0KIAkJCQlyZXR1 cm4gcnMtPnNyX2VycjsNCiAJCQl9DQorCQkJaWYgKCBzcnMtPnNyX3N0YXRl LmN0eGNzbiApIHsNCisJCQkJYmVyX2J2YXJyYXlfZnJlZV94KCBzcnMtPnNy X3N0YXRlLmN0eGNzbiwgb3AtPm9fdG1wbWVtY3R4ICk7DQorCQkJCXNycy0+ c3Jfc3RhdGUuY3R4Y3NuID0gTlVMTDsNCisJCQl9DQorCQkJaWYgKCBzcnMt PnNyX3N0YXRlLnNpZHMgKSB7DQorCQkJCXNsYXBfc2xfZnJlZSggc3JzLT5z cl9zdGF0ZS5zaWRzLCBvcC0+b190bXBtZW1jdHggKTsNCisJCQkJc3JzLT5z cl9zdGF0ZS5zaWRzID0gTlVMTDsNCisJCQl9DQorCQkJc3JzLT5zcl9zdGF0 ZS5udW1jc25zID0gMDsNCiAJCX0gZWxzZSB7DQogCQkJZ290c3RhdGUgPSAx Ow0KIAkJCS8qIElmIGNoYW5nZWQgYW5kIGRvaW5nIFByZXNlbnQgbG9va3Vw LCBzZW5kIFByZXNlbnQgVVVJRHMgKi8NCg== --8323329-1817437300-1213728437=:15378--

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> Well, pre-2.4.9 versions would reject the Add operation... Is it > 2.4.10 built from the OpenLDAP source, or some prepackaged binary? I built RPMs from the source, without any patches: DB: ../dist/configure \ --enable-shared \ --disable-static \ --program-prefix=slapd \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --disable-posixmutexes \ --with-mutex=x86/gcc-assembly \ OL: ./configure \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --datadir=/var/lib \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --libdir=/usr/lib \ --includedir=/usr/include \ --mandir=/usr/share/man \ --enable-backends=mod \ --enable-cleartext \ --enable-crypt \ --enable-ipv6 \ --enable-ldap \ --enable-local \ --enable-modules \ --enable-overlays=mod \ --enable-slapd \ --enable-rewrite \ --enable-syslog \ --with-tls \ --with-threads \ > Maybe an overlay or something interferes with auto-adding the naming > attrs? Please post your slapd.conf too, after removing passwords etc. My sanitized slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/corba.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/krb5-kdc.schema include /etc/openldap/schema/kerberosobject.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/autofs.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/kolab.schema include /etc/openldap/schema/evolutionperson.schema include /etc/openldap/schema/calendar.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/postfix-mail.schema access to dn.exact="" by * read access to dn.subtree="cn=Subschema" by * read access to dn.subtree="ou=people,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=vmail,dc=openldap,dc=example,dc=com" by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by peername.ip=10.12.31.6 anonymous read by peername.ip=10.12.31.7 anonymous read access to dn.subtree="ou=idmap,dc=openldap,dc=example,dc=com" by group="cn=idmap admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by users read by * auth access to attrs=userPassword,sambaLMPassword,sambaNTPassword by self write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by anonymous auth by * none access to * by group="cn=admins,ou=group,dc=openldap,dc=example,dc=com" write by group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" read by self read by anonymous auth pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args #sizelimit unlimited #timelimit unlimited modulepath /usr/sbin/openldap moduleload ppolicy.la moduleload syncprov.la moduleload back_bdb.la moduleload back_monitor.la TLSRandFile /dev/random TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/pki/tls/certs/server01.crt TLSCertificateKeyFile /etc/pki/tls/private/server01.key TLSCACertificateFile /etc/pki/tls/certs/domain-server01.crt security ssf=128 loglevel 256 database config rootdn cn=config rootpw secret #serverid 1 ldap://server03.example.com #serverid 2 ldap://server01.example.com #syncrepl rid=001 # provider=ldap://server01.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #syncrepl rid=002 # provider=ldap://server03.example.com # binddn="cn=config" # bindmethod=simple # credentials=secret # searchbase="cn=config" # type=refreshAndPersist # starttls=yes # tls_reqcert=never # retry="5 5 300 5" # timeout=5 #mirrormode true #overlay syncprov #syncprov-checkpoint 100 10 #syncprov-sessionlog 100 database monitor rootdn cn=monitor rootpw secret database bdb suffix "dc=openldap,dc=example,dc=com" rootdn "cn=manager,dc=openldap,dc=example,dc=com" rootpw secret directory /var/lib/ldap serverid 3 ldap://server01.example.com serverid 4 ldap://server03.example.com cachesize 10000 checkpoint 256 5 syncrepl rid=003 provider=ldap://server01.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 syncrepl rid=004 provider=ldap://server03.example.com binddn="uid=replicator,ou=service-accounts,dc=openldap,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=openldap,dc=example,dc=com" type=refreshAndPersist starttls=yes tls_reqcert=never interval=00:00:00:10 retry="5 5 300 5" timeout=5 mirrormode true overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index sambaSID,sambaDomainName,displayName eq index entryCSN,entryUUID eq index mailid eq limits group="cn=replicator accounts,ou=group,dc=openldap,dc=example,dc=com" size=unlimited time=unlimited Thanks! -- Josh Miller, RHCE

1 0

Re: (ITS#5556) ldapadd/slapadd create objects without RDN
by joshua＠itsecureadmin.com 17 Jun '08

17 Jun '08

> joshua(a)itsecureadmin.com wrote: > >> When adding an object with slapadd or ldapadd, it is possible to create >> an >> object which does not have an RDN, and therefore not searchable by RDN. > > Can't reproduce. Works as expected here (adding entry without naming > attributes/distinguished values results in automatically generating that > data, both by slapadd and ldapadd). Can you confirm software versions? To confirm versions: [root@server01 ldifs]# ldapadd -V ldapadd: @(#) $OpenLDAP: ldapmodify 2.4.10 (Jun 12 2008 11:02:00) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/clients/tools (LDAP library: OpenLDAP 20410) ldap_sasl_interactive_bind_s: Confidentiality required (13) [root@server01 ldifs]# slapd -V @(#) $OpenLDAP: slapd 2.4.10 (Jun 12 2008 11:03:43) $ joshm@server03.sky.dom:/home/SKY/joshm/redhat/BUILD/openldap-2.4.10/servers/slapd I'm running on CentOS 5.1 with DB 4.6 -- I built these RPMs. Thanks, -- Josh Miller, RHCE

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 17 Jun '08

17 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > >> Ah, OK. Note that since some point in 2.3, authorization is described >> by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, >> which should probably be advertised a bit more (and moved out from the >> experimental OID arc). > > If that is used *everywhere* for authorisation then there could well > be more doc errors to correct. I am fairly sure I saw one place where > the docs specifically exclude some of those forms. Yes, I believe in some cases some of the variants of the syntax are not allowed. This is true, for example, in SASL identity mapping, which does not allow the regex, subtree, children, onelevel, group and users styles, only the base and uri forms are allowed (provided the latter only returns a single match). > I notice that '*' excludes anonymous in this spec. There is an > undocumented option to 'allow' that seems relevant: proxy_authz_anon - Why undocumented? It is documented (in 2.4, at least; it does not exist for 2.3). > would allowing this cause anon to be included in '*' generally or is > it not that simple? '*' implies a non-empty value; to include anonymous, use "dn.regex:.*", or "dn.subtree:". 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 17 Jun '08

17 Jun '08

On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote: > Ah, OK. Note that since some point in 2.3, authorization is described > by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, > which should probably be advertised a bit more (and moved out from the > experimental OID arc). If that is used *everywhere* for authorisation then there could well be more doc errors to correct. I am fairly sure I saw one place where the docs specifically exclude some of those forms. I notice that '*' excludes anonymous in this spec. There is an undocumented option to 'allow' that seems relevant: proxy_authz_anon - would allowing this cause anon to be included in '*' generally or is it not that simple? 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#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

Andrew Findlay wrote: > I was referring to documentation, where the only bit of the admin > guide that really talks about proxy authorisation is the SASL section. Ah, OK. Note that since some point in 2.3, authorization is described by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, which should probably be advertised a bit more (and moved out from the experimental OID arc). 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 07:29:12PM +0200, Pierangelo Masarati wrote: > Not sure what you mean there, but I believe the fact that the > implementation is in saslauth.c is for mere historical reasons. Right > now, authorization code is independent from SASL, and is used by a > number of features: SASL authz, RFC 4370, identity assertion, dgIdentity > and more. I was referring to documentation, where the only bit of the admin guide that really talks about proxy authorisation is the SASL section. 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#5555) authzTo ACL check for wrong principal
by ando＠sys-net.it 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk wrote: > It might be better still to factor out the concept of proxy > authorisation and its control from the SASL authz mechanism, as it > applies also to the LDAP Proxied Authorization Control. > I have not done this as I was unsure where best to put it. Not sure what you mean there, but I believe the fact that the implementation is in saslauth.c is for mere historical reasons. Right now, authorization code is independent from SASL, and is used by a number of features: SASL authz, RFC 4370, identity assertion, dgIdentity and more. 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: ando(a)sys-net.it -----------------------------------

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