Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com
> 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
Thanks Howard, here is the info you requested:
(gdb) bt
#0 test_filter (op=0x40fff7f0, e=0x2aab116ab068, f=0x0) at filterentry.c:69
#1 0x00000000004db315 in syncprov_matchops (op=0x410001b0,
opc=0xb096e0, saveit=1) at syncprov.c:1314
#2 0x00000000004db6b5 in syncprov_op_mod (op=0x410001b0, rs=<value
optimized out>) at syncprov.c:2124
#3 0x000000000047e62a in overlay_op_walk (op=0x410001b0,
rs=0x40ffffc0, which=op_modify, oi=0x8d7ab0,
on=0x8dc4f0) at backover.c:659
#4 0x000000000047ec07 in over_op_func (op=0x410001b0, rs=0x40ffffc0,
which=op_modify) at backover.c:721
#5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74d0,
op=0x410001b0, syncCookie=0x41000b20)
at syncrepl.c:3292
#6 0x0000000000478462 in do_syncrep2 (ctx=<value optimized out>,
arg=<value optimized out>)
at syncrepl.c:1097
#7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>)
at syncrepl.c:1455
#8 0x00000000004ec5ec in ldap_int_thread_pool_wrapper
(xpool=0x84daf0) at tpool.c:685
#9 0x000000301b20673d in start_thread (arg=<value optimized out>) at
pthread_create.c:301
#10 0x000000301aad44bd in clone () from /lib64/libc.so.6
(gdb) frame 1
#1 0x00000000004db315 in syncprov_matchops (op=0x410001b0,
opc=0xb096e0, saveit=1) at syncprov.c:1314
1314 rc = test_filter( &op2, e, op2.ors_filter );
(gdb) print *ss
$1 = {s_next = 0x2aab502177f0, s_base = {bv_len = 16, bv_val =
0x2aab730920e0 "dc=test12,dc=net"},
s_eid = 1, s_op = 0x230ea90, s_rid = 1, s_sid = -1, s_filterstr =
{bv_len = 15,
bv_val = 0x230f7d0 "(objectClass=*)"}, s_flags = 1, s_inuse = 1,
s_res = 0x2aababca90f0,
s_restail = 0x2aabc320d920, s_mutex = {__data = {__lock = 0, __count
= 0, __owner = 0, __nusers = 0,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = '\000' <repeats 39 times>, __align = 0}}
12 years, 3 months
(ITS#6969) Need option to show which TLS library is in use
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.4/HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.94.188.8)
Submitted by: hyc
Now that OpenSSL is not the only TLS library that we support, app developers
need a way to check which library is in use. libldap has the info, but due to an
oversight it was not exposed.
The LDAP_OPT_X_TLS_PACKAGE option has been added to retrieve the TLS
implementation name. Currently it may be "OpenSSL", "GnuTLS", or "MozNSS".
12 years, 3 months
Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com
Mark.Cairney(a)ed.ac.uk wrote:
> Full_Name: Mark Cairney
> Version: 2.4.25
> OS: RHEL 5.5 x64
> URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip
> Submission from: (NULL) (129.215.200.77)
>
>
> During provisioning using Grouper (http://www.internet2.edu/grouper) to populate
> a tree of ou and posixGroup objects it looks like the request to create a child
> OU is being issued and granted.
> This results in the creation of a "ghost" parent OU with the glue objectClass as
> documented but syncrepl then constantly tries and fails to provision the ghost
> OU to the other servers (as shown in alderlog.txt).
Your ftp server is demanding authentication, can't download your file.
> My cn=config is listed in cnconfig.txt for reference
>
> The issue can be reproduced by running Grouper's LDAP provisioner with Grouper
> configured to produce a "bushy" structure and it may also be reproduceable if
> provisioning via a suitable large LDIF file (grouper.ldif).
Sorry, I'm not going to install grouper to test this bug. Please provide
scripts to generate data that will reproduce the bug, and please do not use
any 3rd party schemas in the data, that just makes it harder to setup a test
environment.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
(ITS#6968) Glue objectclass created during Grouper provisioning
by Mark.Cairney＠ed.ac.uk
Full_Name: Mark Cairney
Version: 2.4.25
OS: RHEL 5.5 x64
URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip
Submission from: (NULL) (129.215.200.77)
During provisioning using Grouper (http://www.internet2.edu/grouper) to populate
a tree of ou and posixGroup objects it looks like the request to create a child
OU is being issued and granted.
This results in the creation of a "ghost" parent OU with the glue objectClass as
documented but syncrepl then constantly tries and fails to provision the ghost
OU to the other servers (as shown in alderlog.txt).
My cn=config is listed in cnconfig.txt for reference
The issue can be reproduced by running Grouper's LDAP provisioner with Grouper
configured to produce a "bushy" structure and it may also be reproduceable if
provisioning via a suitable large LDIF file (grouper.ldif).
12 years, 3 months
Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com
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/
12 years, 3 months
Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz
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.
12 years, 3 months
Re: (ITS#6892) Segfault in Syncprov overlay
by hyc＠symas.com
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/
12 years, 3 months
Re: (ITS#6967) bug when migrating to cn=config with mixed-case schema names
by hyc＠symas.com
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/
12 years, 3 months
(ITS#6967) bug when migrating to cn=config with mixed-case schema names
by seth＠energysec.org
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.
12 years, 3 months
