openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 19 Oct '07

19 Oct '07

russell-openldap(a)stuart.id.au wrote: > I am trying to insist that connections during sasl auth operations are > encrypted. Ie, that this works: > > access to attrs=userPassword > by tls_ssf=128 ssf=128 anonymous auth > by * none > > It does work for a simple bind. But for a sasl bind it fails, and this telltale > appears in the log: > > slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 > > I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: I suppose that may be a legitimate bug, but this isn't really the correct fix. slap_auxprop_lookup is doing an internal search, so there is no network to speak of. In SSF terms it would have an SSF of "infinity". > diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c > openldap2.3-2.3.30.new/servers/slapd/sasl.c > --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 > +1000 > +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 > +1000 > @@ -384,6 +384,7 @@ > op.ors_slimit = 1; > op.ors_filter = &generic_filter; > op.ors_filterstr = generic_filterstr; > + op.o_authz = conn->c_authz; > /* FIXME: we want all attributes, right? */ > op.ors_attrs = NULL; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 19 Oct '07

19 Oct '07

Full_Name: Russell Stuart Version: 2.3.30 OS: Debian Etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.15.201.110) I am trying to insist that connections during sasl auth operations are encrypted. Ie, that this works: access to attrs=userPassword by tls_ssf=128 ssf=128 anonymous auth by * none It does work for a simple bind. But for a sasl bind it fails, and this telltale appears in the log: slapd[26499]: <= check a_authz.sai_ssf: ACL 128 > OP 0 I fixed the issue using this patch, which applies to 2.4.5, 2.3.38 and 2.3.30: diff -Nur openldap2.3-2.3.30/servers/slapd/sasl.c openldap2.3-2.3.30.new/servers/slapd/sasl.c --- openldap2.3-2.3.30/servers/slapd/sasl.c 2007-10-19 15:27:53.000000000 +1000 +++ openldap2.3-2.3.30.new/servers/slapd/sasl.c 2007-10-19 15:29:18.000000000 +1000 @@ -384,6 +384,7 @@ op.ors_slimit = 1; op.ors_filter = &generic_filter; op.ors_filterstr = generic_filterstr; + op.o_authz = conn->c_authz; /* FIXME: we want all attributes, right? */ op.ors_attrs = NULL;

1 0

(ITS#5194) tpool lockup in RE_24
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) Using latest RE_24, test050 locked up on me. slapd backtrace shows: (gdb) info threads 1 Thread 46912516103168 (LWP 8947) 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038dcc0c758 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038dcc087c4 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038dcc08263 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 #4 0x000000000041d8d5 in config_back_modify (op=0x7fffeb28cc50, rs=0x7fffeb28cdc0) at bconfig.c:4710 #5 0x00002aaaac3d5944 in syncprov_checkpoint (op=0x7fffeb28cec0, rs=<value optimized out>, on=0x1b8df9d0) at syncprov.c:1318 #6 0x00002aaaac3d5f02 in syncprov_db_close (be=0x1b7a6440, cr=<value optimized out>) at syncprov.c:2660 #7 0x0000000000485578 in over_back_response (op=0x1b7c57c0, rs=0x1b7c57c0) at backover.c:234 #8 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x00002aaaaaabc72e in ldap_pvt_thread_pool_resume (tpool=<value optimized out>) at tpool.c:703 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); (gdb) l 698 pool = *tpool; 699 700 if (pool == NULL) 701 return(0); 702 703 ldap_pvt_thread_mutex_lock(&pool->ltp_mutex); 704 pool->ltp_pause = 0; 705 if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING) 706 ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); 707 ldap_pvt_thread_mutex_unlock(&pool->ltp_mutex);

1 0

Re: (ITS#5193) defines.sh error
by hyc＠symas.com 18 Oct '07

18 Oct '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > make[2]: Entering directory `/usr/local/build/ldap-rel-eng-2-4/tests' > Initiating LDAP tests for BDB... > ./scripts/defines.sh: line 55: cd: ./schema: No such file or directory > Running ./scripts/all... >>>>>> Executing all LDAP tests for bdb > > > SCHEMADIR=${USER_SCHEMADIR-./schema} > ABS_SCHEMADIR=`(cd $SCHEMADIR; pwd)` > > Should that be ../schema? Why do we need to cd to it? Nothing is failing so > far by not doing so. That'll only happen the first time. We cd into it so that pwd will tell us the absolute path. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5193) defines.sh error
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) make[2]: Entering directory `/usr/local/build/ldap-rel-eng-2-4/tests' Initiating LDAP tests for BDB... ./scripts/defines.sh: line 55: cd: ./schema: No such file or directory Running ./scripts/all... >>>>> Executing all LDAP tests for bdb SCHEMADIR=${USER_SCHEMADIR-./schema} ABS_SCHEMADIR=`(cd $SCHEMADIR; pwd)` Should that be ../schema? Why do we need to cd to it? Nothing is failing so far by not doing so.

1 0

(ITS#5192) MMR refresh and persist broken
by quanah＠zimbra.com 18 Oct '07

18 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.4.5 beta OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) Refresh and persist MMR mode is broken in 2.4.5 beta. ITS filed for tracking purposes, already fixed in HEAD.

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com 17 Oct '07

17 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> You have to run slapd at least once before using the db_stat tool >> after using slapadd -q. This is a known feature of using -q. > > Ah, need doc fix in slapadd.8 then. What exactly are you trying to do? slapadd -q disables locking, so of course there's nothing for db_stat -c to report. There's no breakage here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5191) Corrupted control value when using pagedresults with subordinate database
by mspeder＠syrtis.net 17 Oct '07

17 Oct '07

Full_Name: Matthieu Speder Version: 2.3.38 & Latest HEAD OS: Linux URL: Submission from: (NULL) (82.224.96.182) When using pagedresults with a subordinate database, the control value of the returned searchResDone is corrupted. * Config part database ldap suffix "dc=test,dc=com" subordinate uri "ldap://ldap2.test.com:389" lastmod off overlay rwm rwm-rewriteEngine on rwm-suffixmassage "dc=test,dc=com" "dc=mainldap,dc=com" * Query : ldapsearch -x -b 'dc=test,dc=com' '(objectclass=*)' -E pr=10 (...) # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= control:: IGZhbHNlIE1Ba0NBUUFFQkFzQUFBQT0= * Packet decode : Lightweight-Directory-Access-Protocol LDAPMessage searchResDone(2) [0 results] messageID: 2 protocolOp: searchResDone (5) controls: 2 items Item pagedResultsControl controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) SearchControlValue size: 0 cookie: <MISSING> Item controlType: \300\3371\b840.113556.1.4.319 controlValue: 300902010004040B000000 0000 00 0c 29 06 cc dd 00 0c 29 1b ea e9 08 00 45 00 ..).....).....E. 0010 00 8e 7b fd 40 00 40 06 a7 ca 0a 00 01 5d 0a 00 ..{.@.@......].. 0020 01 46 01 85 a8 92 c0 a3 d0 9d 5e c3 30 b0 80 18 .F........^.0... 0030 05 a8 2b 24 00 00 01 01 08 0a 01 16 bf 7a 00 00 ..+$.........z.. 0040 1a e9 30 58 02 01 02 65 07 0a 01 00 04 00 04 00 ..0X...e........ 0050 a0 4a 30 21 04 16 31 2e 32 2e 38 34 30 2e 31 31 .J0!..1.2.840.11 0060 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 07 30 05 3556.1.4.319..0. 0070 02 01 00 04 00 30 25 04 16 c0 df 31 08 38 34 30 .....0%....1.840 0080 2e 31 31 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 .113556.1.4.319. 0090 0b 30 09 02 01 00 04 04 0b 00 00 00 .0..........

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no 17 Oct '07

17 Oct '07

quanah(a)zimbra.com writes: > You have to run slapd at least once before using the db_stat tool > after using slapadd -q. This is a known feature of using -q. Ah, need doc fix in slapadd.8 then. -- Hallvard

1 0

Re: (ITS#5189) slapadd -q breaks db_stat -c
by quanah＠zimbra.com 17 Oct '07

17 Oct '07

--On Wednesday, October 17, 2007 1:29 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.3.38 > OS: Linux (x86_64) > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard You have to run slapd at least once before using the db_stat tool after using slapadd -q. This is a known feature of using -q. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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