Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
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/
14 years, 8 months
(ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
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;
14 years, 8 months
(ITS#5194) tpool lockup in RE_24
by quanah＠zimbra.com
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);
14 years, 8 months
Re: (ITS#5193) defines.sh error
by hyc＠symas.com
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/
14 years, 8 months
(ITS#5193) defines.sh error
by quanah＠zimbra.com
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.
14 years, 8 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by hyc＠symas.com
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/
14 years, 8 months
(ITS#5191) Corrupted control value when using pagedresults with subordinate database
by mspeder＠syrtis.net
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..........
14 years, 8 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by h.b.furuseth＠usit.uio.no
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
14 years, 8 months
Re: (ITS#5189) slapadd -q breaks db_stat -c
by quanah＠zimbra.com
--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
14 years, 8 months
