(ITS#6759) assert;Debug -> Debug;assert
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version:
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
OpenLDAP sometimes does assert() before Debug(). assert is more
convenient after Debug, so more info is readily available for
debugging. Except when the assert catches that Debug would crash.
I'll update some cases, including for soon-to-be-committed asserts.
12 years, 11 months
(ITS#6758) Cleaning up SlapReply usage
by h.b.furuseth@usit.uio.no
Full_Name: Hallvard B Furuseth
Version: 2.4.23, HEAD
OS: Linux x86_64
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Slapd and its modules put varous info in SlapReply and send it.
They do not always clean it up afterwards, or not correctly. Then
they sometimes reuse the SlapReply without reinitializing, even
though most of its fields are invalid at that point. (In practice
they are usually mostly zeroed by then, so slapd works anyway.)
This is a dup of the misnamed ITS#5340, so the CHANGES file can
refer to an ITS with a better name for all the upcoming commits.
Also I'll go about it a bit backwards than discussed there:
First reset some flags and avoid reusing SlapReply, then get
more aggressive about obeying the flag settings that remain.
12 years, 11 months
(ITS#6757) SASL canonicalize doesn't work as documented
by b.candler@pobox.com
Full_Name: Brian Candler
Version: 2.4.21
OS: Ubuntu 10.04.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.114.104.19)
DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two
example authorization DNs built from SASL/GSSAPI:
"a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated
DN:
uid=kurt,cn=example.com,cn=gssapi,cn=auth
and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN:
uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth"
Experimentation shows that the actual behaviour is different.
(1) If the realm of the client is the same as the default_realm on the server,
then the auth DN is
uid=kurt,cn=<olcSaslRealm>,cn=gssapi,cn=auth
(2) If the realm of the client is different to the default_realm on the server,
then the auth DN is
uid=ursula/admin(a)foreign.realm,cn=<olcSaslRealm>,cn=gssapi,cn=auth
(If olcSaslRealm is unset in the config then cn=<olcSaslRealm> is omitted
entirely)
Some real examples are shown below. I reproduced this in a cross-realm auth
setup with two MIT Kerberos 1.8.1 KDCs. The realms are WS.NSRC.ORG and
REALM3.WS.NSRC.ORG. The server is host noc.ws.nsrc.org and is in realm
WS.NSRC.ORG. It has a keytab for ldap/noc.ws.nsrc.org(a)WS.NSRC.ORG, and has
olcSaslRealm: EXAMPLE.COM (which is just a junk realm, but it makes it clear
that this isn't used for authentication)
When a client presents a ticket for inst(a)WS.NSRC.ORG:
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=<continuing> datalen=32
SASL Canonicalize [conn=1000]: authcid="inst"
slap_sasl_getdn: conn 1000 id=inst [len=4]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
>>> dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0
<<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name uid=inst,cn=example.com,cn=gssapi,cn=auth
to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=1000]:
slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth"
SASL proxy authorize [conn=1000]: authcid="inst(a)EXAMPLE.COM"
authzid="inst(a)EXAMPLE.COM"
SASL Authorize [conn=1000]: proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth"
sasl_ssf=56
When a client presents a ticket for student(a)REALM3.WS.NSRC.ORG:
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=<continuing> datalen=32
SASL Canonicalize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG"
slap_sasl_getdn: conn 1000 id=student(a)REALM3.WS.NSRC.ORG [len=26]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
slap_sasl_getdn: u:id converted to
uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth
>>> dnNormalize:
<uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0
<<< dnNormalize:
<uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name
uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=1000]:
slapAuthcDN="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth"
SASL proxy authorize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG"
authzid="student(a)REALM3.WS.NSRC.ORG"
SASL Authorize [conn=1000]: proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/GSSAPI bind:
dn="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth"
sasl_ssf=56
You can see that the authcid from libsasl omits the realm when it's the same as
the server's, and includes the realm when it's different. However openldap does
not split out into "uid=ursula/admin,cn=foreign.realm" as the documentation
says.
You could treat this either as a behaviour error or a documentation error - if
the latter, the olcSaslRealm is pretty useless, because if set it appears in all
auth DNs (for both local and foreign realms)
12 years, 11 months
Re: (ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour@brightcove.com
--90e6ba211d7d01d52c0498a713c3
Content-Type: text/plain; charset=ISO-8859-1
oops, sorry, this is a duplicate
On Thu, Dec 30, 2010 at 4:06 PM, <openldap-its(a)openldap.org> wrote:
>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System. Your
> report has been assigned the tracking number ITS#6756.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers. They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message. Note that
> any mail sent to openldap-its(a)openldap.org with (ITS#6756)
> in the subject will automatically be attached to the issue report.
>
> mailto:openldap-its@openldap.org?subject=(ITS#6756)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
> http://www.OpenLDAP.org/its/index.cgi?findid=6756
>
> Please remember to retain your issue tracking number (ITS#6756)
> on any further messages you send to us regarding this report. If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
> http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>
>
--
Josh Gilmour | Windows Systems & Network Administrator
Brightcove, Inc. www.brightcove.com
One Cambridge Center, 12th Floor, Cambridge, MA 02142
P: 617.395.5843 F: 617.395.8352
++++++++++
Brightcove PLAY 2011 Global Customer Conference
May 23-25, Boston Seaport Hotel & World Trade Center
Registration Now Open: http://brightcove.com/play2011
++++++++++
--90e6ba211d7d01d52c0498a713c3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
oops, sorry, this is a duplicate<br><br><div class=3D"gmail_quote">On Thu, =
Dec 30, 2010 at 4:06 PM, <span dir=3D"ltr"><<a href=3D"mailto:openldap-=
its(a)openldap.org">openldap-its(a)openldap.org</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex;">
<br>
*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br>
<br>
Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your<br>
report has been assigned the tracking number ITS#6756.<br>
<br>
One of our support engineers will look at your report in due course.<br>
Note that this may take some time because our support engineers<br>
are volunteers. =A0They only work on OpenLDAP when they have spare<br>
time.<br>
<br>
If you need to provide additional information in regards to your<br>
issue report, you may do so by replying to this message. =A0Note that<br>
any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@=
openldap.org</a> with (ITS#6756)<br>
in the subject will automatically be attached to the issue report.<br>
<br>
=A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda=
p-its(a)openldap.org</a>?subject=3D(ITS#6756)<br>
<br>
You may follow the progress of this report by loading the following<br>
URL in a web browser:<br>
=A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D6756" tar=
get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D6756</a><br>
<br>
Please remember to retain your issue tracking number (ITS#6756)<br>
on any further messages you send to us regarding this report. =A0If<br>
you don't then you'll just waste our time and yours because we<br>
won't be able to properly track the report.<br>
<br>
Please note that the Issue Tracking System is not intended to<br>
be used to seek help in the proper use of OpenLDAP Software.<br>
Such requests will be closed.<br>
<br>
OpenLDAP Software is user supported.<br>
=A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla=
nk">http://www.OpenLDAP.org/support/</a><br>
<br>
--------------<br>
Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Josh Gilmour | Windows =
Systems & Network Administrator<br><br>Brightcove, Inc. <a href=3D"http=
://www.brightcove.com">www.brightcove.com</a><br>One Cambridge Center, 12th=
Floor, Cambridge, MA 02142<br>
P: 617.395.5843 F: 617.395.8352 <br><br>++++++++++<br><br>Brightcove PLAY 2=
011 Global Customer Conference<br><br>May 23-25, Boston Seaport Hotel &=
World Trade Center<br><br>Registration Now Open: <a href=3D"http://brightc=
ove.com/play2011">http://brightcove.com/play2011</a><br>
<br>++++++++++<br><br><br>
--90e6ba211d7d01d52c0498a713c3--
12 years, 11 months
(ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour@techsmog.com
Full_Name: Josh Gilmour
Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14)
OS: CentOS release 5.4 32bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (38.112.23.58)
I get a segfault when using the following command and applying a filter file. If
we remove the -f, the command runs properly. It doesn't seem to be a major
security issue (or one at all, I'm not sure), but it does seem to be a bug I
believe...
the file i'm using for the -f parameter, 'testing', just has the letter 'a' in
it.
Here is the process output from gdb:
[jgilmour@xijgilmour ~]$ gdb ldapsearch
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b
"OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing
Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E
pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f
testing
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
dn: OU=xxx,DC=xxx,DC=LOCAL
objectClass: top
objectClass: organizationalUnit
ou: xxx
distinguishedName: OU=xxx,DC=xxx,DC=LOCAL
instanceType: 4
whenCreated: 20050103174000.0Z
whenChanged: 20081117191042.0Z
uSNCreated: 12371
uSNChanged: 6388825
name: xxx
objectGUID:: qjRiugCNd0eXyrXkHlETpA==
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D
C=LOCAL
dSCorePropagationData: 20080818221029.0Z
dSCorePropagationData: 20080628202026.0Z
dSCorePropagationData: 20070611215308.0Z
dSCorePropagationData: 20070611213209.0Z
dSCorePropagationData: 16010714223649.0Z
*** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev):
0x086a35f8 ***
Program received signal SIGSEGV, Segmentation fault.
0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6
(gdb) i r
eax 0x169 361
ecx 0xd43170 13906288
edx 0x86a35f0 141178352
ebx 0xd41ff4 13901812
esp 0xbf9a7078 0xbf9a7078
ebp 0xbf9a713c 0xbf9a713c
esi 0x168 360
edi 0xb7fdb000 -1208111104
eip 0xc67a3f 0xc67a3f <_int_malloc+703>
eflags 0x210283 [ CF SF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) bt
#0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6
#1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6
#2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2
#3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2
#4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2
#5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2
#6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6
#7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2
#8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6
#9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6
#10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6
#11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6
#12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6
#13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6
#14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6
#15 0x0804ca88 in ?? ()
#16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6
#17 0x0804a3f1 in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
[jgilmour@xijgilmour ~]$ uname -a
Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST
2010 i686 i686 i386 GNU/Linux
12 years, 11 months
(ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour@techsmog.com
Full_Name: Josh Gilmour
Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14)
OS: CentOS release 5.4 32bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (38.112.23.58)
I get a segfault when using the following command and applying a filter file. If
we remove the -f, the command runs properly. It doesn't seem to be a major
security issue (or one at all, I'm not sure), but it does seem to be a bug I
believe...
the file i'm using for the -f parameter, 'testing', just has the letter 'a' in
it.
Here is the process output from gdb:
[jgilmour@xijgilmour ~]$ gdb ldapsearch
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b
"OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing
Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E
pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f
testing
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
dn: OU=xxx,DC=xxx,DC=LOCAL
objectClass: top
objectClass: organizationalUnit
ou: xxx
distinguishedName: OU=xxx,DC=xxx,DC=LOCAL
instanceType: 4
whenCreated: 20050103174000.0Z
whenChanged: 20081117191042.0Z
uSNCreated: 12371
uSNChanged: 6388825
name: xxx
objectGUID:: qjRiugCNd0eXyrXkHlETpA==
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D
C=LOCAL
dSCorePropagationData: 20080818221029.0Z
dSCorePropagationData: 20080628202026.0Z
dSCorePropagationData: 20070611215308.0Z
dSCorePropagationData: 20070611213209.0Z
dSCorePropagationData: 16010714223649.0Z
*** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev):
0x086a35f8 ***
Program received signal SIGSEGV, Segmentation fault.
0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6
(gdb) i r
eax 0x169 361
ecx 0xd43170 13906288
edx 0x86a35f0 141178352
ebx 0xd41ff4 13901812
esp 0xbf9a7078 0xbf9a7078
ebp 0xbf9a713c 0xbf9a713c
esi 0x168 360
edi 0xb7fdb000 -1208111104
eip 0xc67a3f 0xc67a3f <_int_malloc+703>
eflags 0x210283 [ CF SF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) bt
#0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6
#1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6
#2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2
#3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2
#4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2
#5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2
#6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6
#7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2
#8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6
#9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6
#10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6
#11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6
#12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6
#13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6
#14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6
#15 0x0804ca88 in ?? ()
#16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6
#17 0x0804a3f1 in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
[jgilmour@xijgilmour ~]$ uname -a
Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST
2010 i686 i686 i386 GNU/Linux
12 years, 11 months
(ITS#6754) slapd ignores extra command-line arguments
by rein@OpenLDAP.org
Full_Name: Rein Tollevik
Version: CVS head
OS: Irrelevant
URL:
Submission from: (NULL) (2a01:600:0:1:129a:ddff:fe4b:9c78)
Submitted by: rein
slapd silently ignores extra command-line arguments not recognized as options.
A simple fix is coming.
--
Rein Tollevik
Basefarm AS
12 years, 11 months
Re: (ITS#6741)
by hyc@symas.com
jgcardoso(a)seguridata.com wrote:
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01CBA84D.397A800E
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> I submitted a patch for tls2.c in order to handle DER BitString values.
LBER_BITSTRING is already defined in lber.h so there's no need to define
LBER_TAG_BITSTRING in your patch.
I will clean up some of this and then commit it.
--
-- 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, 11 months
(ITS#6741)
by jgcardoso@seguridata.com
This is a multi-part message in MIME format.
------_=_NextPart_001_01CBA84D.397A800E
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I submitted a patch for tls2.c in order to handle DER BitString values.
=20
This patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by SeguriData Privada, S.A. de CV.
SeguriData Privada S.A de C. V. has not assigned rights and/or interest
in this work to any party.
I, Juan Gonzalez Cardoso am authorized by SeguriData Privada, S. A. de
C. V., my employer, to release this work under the following terms:
=20
The attached modifications to OpenLDAP Software are subject to the
following notice:
=20
Copyright SeguriData Privada, S. A. de C. V.
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public
License.
=20
Full_Name: Juan Gonzalez Cardoso
Version: 2.4.23
OS: Red Hat 5.5 EL
URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch
=20
=20
=20
=20
------_=_NextPart_001_01CBA84D.397A800E
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DES-MX link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
lang=3DEN-US>I submitted a patch for tls2.c in order to handle DER =
BitString values.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US> This patch file is derived from OpenLDAP Software. All of =
the modifications to OpenLDAP Software represented in the following =
patch(es) were developed by SeguriData Privada, S.A. de =
CV.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>SeguriData Privada S.A de C. V. has not assigned rights =
and/or interest in this work to any party.<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>I, Juan Gonzalez Cardoso am =
authorized by SeguriData Privada, S. A. de C. V., my employer, to =
release this work under the following terms:<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>The attached modifications to =
OpenLDAP Software are subject to the following =
notice:<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal>Copyright =
SeguriData Privada, S. A. de C. V.<o:p></o:p></p><p =
class=3DMsoNormal><span lang=3DEN-US>Redistribution and use in source =
and binary forms, with or without modification, are permitted only as =
authorized by the OpenLDAP Public License.<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US><o:p> </o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>Full_Name: Juan Gonzalez =
Cardoso<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>Version: 2.4.23<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>OS: Red Hat 5.5 =
EL<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>URL: <a =
href=3D"ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch">ftp:/=
/ftp.openldap.org/incoming/juan-gonzalez-101230.patch</a><o:p></o:p></spa=
n></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p> </o:p></span></p></div></body></html>
------_=_NextPart_001_01CBA84D.397A800E--
12 years, 11 months
Re: (ITS#6684)
by hyc@symas.com
norbert(a)pueschel.net wrote:
> Updated TAR-file with (hopefully) sufficient copyright notice...
>
> http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar
Your code does a string compare againset "memberOf" to detect those filter
references.
1) it should simply be comparing the AttributeDescription pointers
2) since the "memberof" attribute is actually configurable in the memberof
overlay, there's no guarantee that this is the correct attribute to be looking
for. It should also be configurable in your patch.
You're using strcasecmp, but your inputs are already normalized values. You
should just use ber_bvcmp.
Replying to the original:
> 1) Using non-DN-valued URIs for autogroup does not work correctly, even
> with the latest version from HEAD. Especially changing group member is
> not tracked.
I don't see why this should ever work or be supported. LDAP groups list DNs.
> 2) Using the memberOf-overlay for constructing autogroups does not work
I don't see any reason why this should work. The memberof overlay is not used
to construct groups, it is only used to report on group memberships that have
already been defined.
--
-- 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, 11 months