openldap-bugs

openldap-bugs@openldap.org

20960 discussions

Re: (ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > This can be solved along with ITS#5792 relatively easily from within > entry_schema_check(), provided the structuralObjectClass attribute is not > indexed. Otherwise, things get a little bit more complicated. Fixed in HEAD, including the (unlikely) case structuralObjectClass is indexed. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.100.26) Submitted by: ando When the structural objectClass of an entry is modified, the corresponding structuralObjectClass attr is not modified accordingly. While addressing ITS#5792, I found out that the only other case that allows modification of the structural objectClass of an object, from "glue" to any other class using the manageDSAit control, results in an entry with the objectClass attribute set to the modified values, while the structuralObjectClass attribute remains "glue". This can be solved along with ITS#5792 relatively easily from within entry_schema_check(), provided the structuralObjectClass attribute is not indexed. Otherwise, things get a little bit more complicated. p.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by h.b.furuseth＠usit.uio.no 04 Feb '09

04 Feb '09

I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > Philippe.eychart(a)informatique.gov.pf wrote: > >> The "tool_conn_setup" function (in common.c) autorise the Url synthaxe >> "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server >> to request (not yet according the rfc 2782 - I've made dnssrv.c patch to >> implement priorities and I try to implement weight before submit this work). So, >> the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via >> "ldap_dn2domain" and "ldap_domain2hostlist" functions). > > This was done to allow testing client-side the DNS SRV feature. > >> Unfortunately, ldap_initialize() doesn't use these functions (but only >> ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages >> (like SAMBA) doesn't enjoy this capability : "passdb backend = >> ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition >> "_ldap._tcp.my.domain. IN SRV ..." >> >> Is there any reason for that ? Can we envisage to increase this possibility ? > > None that I'm aware of. Feel free to move that code from tools to > libldap. Patches are welcome, as usual. But please put a note into the accompanying man-page with a strong recommendation not to use it without further security mechs. I wouldn't configure Samba like this. (Similar problems like DNS lookups in Kerberos implementations for realm- and KDC-discovery.) I've implemented something like this in web2ldap but the SRV mech causes an user interaction on the UI. So the user has a vague chance to determine whether he's tricked to another DSA by DNS spoofing. Ciao, Michael.

1 0

Re: (ITS#5920) segfault in sockbuf.c
by hyc＠symas.com 04 Feb '09

04 Feb '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 01/30/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I link postfix against OpenLDAP libraries for its ldap lookups. With my > previous CVS checkout of RE24 (12/9/2008) there were no problems with this. > However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap > binary always segfaults: > This is likely related to the recent TLS changes in RE24. Yes, fixed in HEAD. -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Philippe.eychart(a)informatique.gov.pf wrote: > The "tool_conn_setup" function (in common.c) autorise the Url synthaxe > "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server > to request (not yet according the rfc 2782 - I've made dnssrv.c patch to > implement priorities and I try to implement weight before submit this work). So, > the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via > "ldap_dn2domain" and "ldap_domain2hostlist" functions). This was done to allow testing client-side the DNS SRV feature. > Unfortunately, ldap_initialize() doesn't use these functions (but only > ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages > (like SAMBA) doesn't enjoy this capability : "passdb backend = > ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition > "_ldap._tcp.my.domain. IN SRV ..." > > Is there any reason for that ? Can we envisage to increase this possibility ? None that I'm aware of. Feel free to move that code from tools to libldap. Patches are welcome, as usual. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5920) segfault in sockbuf.c
by quanah＠zimbra.com 04 Feb '09

04 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 01/30/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I link postfix against OpenLDAP libraries for its ldap lookups. With my previous CVS checkout of RE24 (12/9/2008) there were no problems with this. However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap binary always segfaults: Core was generated by `proxymap -t unix -u'. Program terminated with signal 11, Segmentation fault. [New process 19154] #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 168 sockbuf.c: No such file or directory. in sockbuf.c (gdb) bt #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 #1 0xb7e21eaf in ldap_pvt_tls_inplace (sb=0x807bfc0) at tls2.c:456 #2 0xb7e21f2c in ldap_tls_inplace (ld=0x807ce18) at tls2.c:475 #3 0xb7e22e84 in ldap_start_tls_s (ld=0x807ce18, serverctrls=0x0, clientctrls=0x0) at tls2.c:922 #4 0x080514aa in dict_ldap_connect (dict_ldap=0x807ca08) at dict_ldap.c:711 #5 0x0805257e in dict_ldap_lookup (dict=0x807ca08, name=0x807cbc8 "*") at dict_ldap.c:1123 #6 0x0804b590 in proxymap_service (client_stream=0x80799a8, unused_service=0xbf8cbf6d "proxymap", argv=0xbf8c9f24) at proxymap.c:354 #7 0x0804c5d2 in multi_server_execute (unused_event=1, context=0x80799a8 "") at multi_server.c:311 #8 0x0805b08d in event_loop (delay=-1) at events.c:1079 #9 0x0804bee0 in multi_server_main (argc=4, argv=0xbf8c9f14, service=0x804b1b0 <proxymap_service>) at multi_server.c:841 #10 0x0804add4 in main (argc=4, argv=0xbf8c9f14) at proxymap.c:651 (gdb) print *sb $2 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 0}, sb_iod = 0x0, sb_fd = -1, sb_max_incoming = 0, sb_trans_needs_read = 0, sb_trans_needs_write = 0} This is likely related to the recent TLS changes in RE24.

1 0

(ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 03 Feb '09

03 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My first work ... -----Message d'origine----- De : openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Envoy=E9 : mardi 3 f=E9vrier 2009 11:02 =C0 : Philippe.eychart(a)informatique.gov.pf Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=3Dmy%2cdc=3Ddomaine) *** 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#5919. 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#5919) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#5919) 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=3D5919 Please remember to retain your issue tracking number (ITS#5919) 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. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: application/octet-stream; name="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" --- openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-23 = 20:56:43.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-24 = 01:00:47.000000000 +0000=0A= # This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the following = patch(es) were developed by Philippe.EYCHART(a)mail.pf. I have not = assigned rights and/or interest in this work to any party.=0A= # this patch for more compliance with RFC 2782 : the result string is = sorted by priorities (SRV rr) in function ldap_domain2hostlist() ... not = yet according weight :-(=0A= @@ -223,10 +223,14 @@=0A= #endif=0A= if (len >=3D 0) {=0A= unsigned char *p;=0A= - char host[DNSBUFSIZ];=0A= + struct hostInfo {=0A= + char name[DNSBUFSIZ];=0A= + int priority;=0A= + /* int weight; */=0A= + u_short port;=0A= + } *host =3D NULL;=0A= + int curhost=3D0;=0A= int status;=0A= - u_short port;=0A= - /* int priority, weight; */=0A= =0A= /* Parse out query */=0A= p =3D reply;=0A= @@ -242,8 +246,15 @@=0A= p +=3D sizeof(HEADER);=0A= #endif=0A= =0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + host =3D (struct hostInfo *) LDAP_MALLOC (sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + goto out;=0A= + }=0A= +=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -251,8 +262,9 @@=0A= =0A= while (p < reply + len) {=0A= int type, class, ttl, size;=0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -265,35 +277,61 @@=0A= size =3D (p[0] << 8) | p[1];=0A= p +=3D 2;=0A= if (type =3D=3D T_SRV) {=0A= - int buflen;=0A= - status =3D dn_expand(reply, reply + len, p + 6, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p + 6, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= - /* ignore priority and weight for now */=0A= - /* priority =3D (p[0] << 8) | p[1]; */=0A= - /* weight =3D (p[2] << 8) | p[3]; */=0A= - port =3D (p[4] << 8) | p[5];=0A= + host[curhost].priority =3D (p[0] << 8) | p[1];=0A= + /* ignore weight for now */=0A= + /* host[curhost].weight =3D (p[2] << 8) | p[3]; */=0A= + host[curhost].port =3D (p[4] << 8) | p[5];=0A= =0A= - if ( port =3D=3D 0 || host[ 0 ] =3D=3D '\0' ) {=0A= + if ( host[curhost].port =3D=3D 0 || host[curhost].name[ 0 ] =3D=3D = '\0' ) {=0A= goto add_size;=0A= }=0A= =0A= - buflen =3D strlen(host) + STRLENOF(":65355 ");=0A= - hostlist =3D (char *) LDAP_REALLOC(hostlist, cur + buflen + 1);=0A= - if (hostlist =3D=3D NULL) {=0A= + curhost++;=0A= + host =3D (struct hostInfo *) LDAP_REALLOC (host, (curhost + 1) * = sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= rc =3D LDAP_NO_MEMORY;=0A= goto out;=0A= }=0A= - if (cur > 0) {=0A= - /* not first time around */=0A= - hostlist[cur++] =3D ' ';=0A= - }=0A= - cur +=3D sprintf(&hostlist[cur], "%s:%hd", host, port);=0A= +=0A= }=0A= add_size:;=0A= p +=3D size;=0A= }=0A= +=0A= + if ( host[0].name[ 0 ] ) {=0A= + int nbhosts=3Dcurhost, bull;=0A= + unsigned char buffer[sizeof (struct hostInfo)]; // :(=0A= +=0A= + // sort hosts by priorities ...=0A= + for (bull=3D(char)1; bull; ) { bull=3D(char)0;=0A= + for ( curhost=3D1; curhost < nbhosts; curhost++ ) {=0A= + if ( host[curhost].priority < host[curhost-1].priority ) {=0A= + bull =3D (char)1;=0A= + memcpy ( (struct hostInfo *)buffer, &host[curhost-1], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost-1], &host[curhost], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost], (struct hostInfo *)buffer, sizeof = (struct hostInfo));=0A= + } } }=0A= +=0A= + // do hostlist, string result ...=0A= + for ( cur=3Dcurhost=3D0; curhost < nbhosts; curhost++ ) {=0A= +=0A= + hostlist =3D (char *) LDAP_REALLOC (hostlist, cur + = strlen(host[curhost].name) + STRLENOF(":65535 ") + 1);=0A= + if (hostlist =3D=3D NULL) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + LDAP_FREE (host);=0A= + goto out;=0A= + }=0A= + cur +=3D sprintf(&hostlist[cur], "%s:%hd ", host[curhost].name, = host[curhost].port);=0A= +=0A= + } hostlist[cur] =3D '\0'; /* remove last ' ' */=0A= + }=0A= +=0A= + LDAP_FREE (host);=0A= }=0A= if (hostlist =3D=3D NULL) {=0A= /* No LDAP servers found in DNS. */=0A= ------=_NextPart_000_002C_01C985F1.ABA10980--

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