openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 10 Jun '11

10 Jun '11

Daniel Pluta wrote: > Howard Chu wrote: >> daniel at pluta.biz wrote: >>> Please also have a look into the might be related patch, submitted in >>> ITS#6912 which addresses normalization of auth(c|z)Id of the form >>> "u:xxx" in general. Thank you very much. >> >> I see no bug here. The backslash was properly escaped, using the normal >> escaping rules for LDAP DNs. >> > > Yeah, you are right, but ... ;-) > ... I'm perhaps too. So please let me try to explain: > > The backslash is syntactically correct escaped (under the assumtion that > the string is indeed a "LDAP DN"). > > In my opinion authz-regexp (a slapd-config-statement string) completely > or partly does not always represent a "LDAP DN". It's quite often more > or less a combination of > > LDAP URI + optional regex + its optional expansions > > which probably should not be treated in general (especially in regard to > normalization) like a LDAP DN. > > This has led me to the submitted patch in ITS#6912 where I assume that > in contrast to authDN-normalization, the normalization of authIDs > (u:xxxx) in general is probably quite problematic, too... > > I'm aware that LDAP DNs need to be normalized in general, but I do not > understand why authcIDs or authz-regexp-expansions should need to be > normalized in general, too. > The authz-regexp expansion does not "need" to be normalized. But it is fed a DN, and that DN is normalized before any further processing, so if you want to match it, you must use the proper normalized string in your regexp: use "\\5C" instead of "\\". Next time send your usage questions to the -technical mailing list. This ITS is closed. -- -- 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#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 10 Jun '11

10 Jun '11

Howard Chu wrote: > daniel at pluta.biz wrote: >> Please also have a look into the might be related patch, submitted in >> ITS#6912 which addresses normalization of auth(c|z)Id of the form >> "u:xxx" in general. Thank you very much. > > I see no bug here. The backslash was properly escaped, using the normal > escaping rules for LDAP DNs. > Yeah, you are right, but ... ;-) ... I'm perhaps too. So please let me try to explain: The backslash is syntactically correct escaped (under the assumtion that the string is indeed a "LDAP DN"). In my opinion authz-regexp (a slapd-config-statement string) completely or partly does not always represent a "LDAP DN". It's quite often more or less a combination of LDAP URI + optional regex + its optional expansions which probably should not be treated in general (especially in regard to normalization) like a LDAP DN. This has led me to the submitted patch in ITS#6912 where I assume that in contrast to authDN-normalization, the normalization of authIDs (u:xxxx) in general is probably quite problematic, too... I'm aware that LDAP DNs need to be normalized in general, but I do not understand why authcIDs or authz-regexp-expansions should need to be normalized in general, too.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by hyc＠symas.com 10 Jun '11

10 Jun '11

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.25 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.10.36.147) > > > In my configuration slapd segfaults within a few hours repeatably when a NULL > value is somehow passed as a filter to test_filter in the syncprov overlay. > > I'm running "threads 64" as I have 62 consumers connecting and this was required > to prevent unrelated searches from timing out when all the consumers connect at > once. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x59832940 (LWP 2042)] > test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > 69 if ( f->f_choice& SLAPD_FILTER_UNDEFINED ) { > (gdb) bt > #0 test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > #1 0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750, > saveit=1) at syncprov.c:1314 > #2 0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized > out>) at syncprov.c:2124 > #3 0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40, > which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659 > #4 0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40, > which=op_modify) at backover.c:721 > #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130, > syncCookie=0x59831aa0) at syncrepl.c:3292 > #6 0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value > optimized out>) at syncrepl.c:959 > #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at > syncrepl.c:1455 > #8 0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value > optimized out>) at connection.c:1251 > #9 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at > tpool.c:685 > #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at > pthread_create.c:301 > #11 0x000000301aad44bd in clone () from /lib64/libc.so.6 > > Let me know if I can provide more info. A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: frame 1 print *ss -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by hyc＠symas.com 10 Jun '11

10 Jun '11

seth(a)energysec.org wrote: > Full_Name: Seth B. > Version: 2.4.25 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.37.253.46) > > > I moved from slapd.conf to cn=config using options -F and -f (forgot the exact > command but I think it was slapadd). I had a schema called EnergySec.ldif that > was migrated. It showed up as > /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif > following the conversion. > > However, when I tried modifying the schema using ADS and then ldapmodify, I > would get a error 32: No such object. With slapd in foreground mode, I found > that it was trying to access the lower-case version of the file: > > ldif_read_file: no entry file > "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" > > Since UNIX is case-sensitive, this obviously failed (the import kept the case as > EnergySec.ldif). > > I fixed it by manually renaming the ldif file to lower case and changing the dn > and cn inside the file. That was pretty hairy and I hope I didn't break anything > else but it semes to work. Thanks for the report, this is now fixed in git master. -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by seth＠energysec.org 09 Jun '11

09 Jun '11

Full_Name: Seth B. Version: 2.4.25 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.37.253.46) I moved from slapd.conf to cn=config using options -F and -f (forgot the exact command but I think it was slapadd). I had a schema called EnergySec.ldif that was migrated. It showed up as /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif following the conversion. However, when I tried modifying the schema using ADS and then ldapmodify, I would get a error 32: No such object. With slapd in foreground mode, I found that it was trying to access the lower-case version of the file: ldif_read_file: no entry file "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" Since UNIX is case-sensitive, this obviously failed (the import kept the case as EnergySec.ldif). I fixed it by manually renaming the ldif file to lower case and changing the dn and cn inside the file. That was pretty hairy and I hope I didn't break anything else but it semes to work.

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 09 Jun '11

09 Jun '11

daniel(a)pluta.biz wrote: > Please also have a look into the might be related patch, submitted in > ITS#6912 which addresses normalization of auth(c|z)Id of the form > "u:xxx" in general. Thank you very much. I see no bug here. The backslash was properly escaped, using the normal escaping rules for LDAP DNs. -- -- 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#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 09 Jun '11

09 Jun '11

Please also have a look into the might be related patch, submitted in ITS#6912 which addresses normalization of auth(c|z)Id of the form "u:xxx" in general. Thank you very much.

1 0

Re: (ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠zimbra.com 09 Jun '11

09 Jun '11

--On Thursday, June 09, 2011 10:19 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The admin guide refers to "Start TLS" in multiple locations instead of > "StartTLS", which leads to confusion among end users, and makes searching > for the startTLS pieces a pain. I will fix shortly. > I will mark this as invalid, as this is how it is described in all the RFCs as well (Start TLS). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.23 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi all, > > We have an issue on one of our production systems whereby openldap is not > enforcing the ACLs on a back-perl subordinate database. Keep in mind, this is back-perl's documented behavior. >>> ACCESS CONTROL The perl backend does not honor any of the access control semantics described in slapd.access(5); all access control is delegated to the underlying PERL scripting. Only read (=r) access to the entry pseudo- attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. <<< Treating this as an enhancement request. > In this particular system, the membership of certain groups stored within LDAP > is determined by some customised logic in a Perl module which dynamically > generates LDAP objects with posixGroup/groupOfNames entries conditionally based > upon the values of existing LDAP attributes within the tree. However, since > these internal LDAP attribute lookups can be quite slow, we wish to hide them > from all but a small minority of bind DNs. Unfortunately what we are finding is > that the back-perl module is not respecting the ACLs in slapd.conf. > > The following files can be used to reproduce this issue with openldap 2.4.23: > > http://pastebin.siriusit.co.uk/perlacl/slapd.conf > http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif > http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm > > The password for both the "cn=admin,dc=my-domain,dc=com" and the > "cn=restricted,dc=my-domain,dc=com" DNs is secret. > > The ACLs in the above slapd.conf look like this: > > access to dn.subtree="ou=perl,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to dn.subtree="ou=hidden,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to * > by dn="cn=admin,dc=my-domain,dc=com" write > by dn="cn=restricted,dc=my-domain,dc=com" read > by * auth > > Using these ACLs, I would expect that cn=admin should be able to read the whole > directory, whereas cn=restricted should not be able to see either the > "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" > DN subtree. > > However, performing an LDAP search binding as cn=restricted gives the following > output: > > build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D > 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW > Enter LDAP Password: > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: real > > dn: ou=realtest1,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest1 > > dn: ou=realtest2,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest2 > > dn: ou=realtest3,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest3 > > dn: ou=realtest4,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest4 > > dn: ou=realtest5,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest5 > > dn: cn=restricted,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn: restricted > description: restricted user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: cn=admin,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn:: YWRtaW4g > description: admin user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: ou=perltest5,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest5 > > dn: ou=perltest4,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest4 > > dn: ou=perltest3,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest3 > > dn: ou=perltest2,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest2 > > dn: ou=perltest1,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest1 > > > In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden > from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree > is not. > > -- -- 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#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠OpenLDAP.org 09 Jun '11

09 Jun '11

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The admin guide refers to "Start TLS" in multiple locations instead of "StartTLS", which leads to confusion among end users, and makes searching for the startTLS pieces a pain. I will fix shortly.

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