- openldap-bugs - openldap.org

Re: authzTo ACL check for wrong principal (ITS#5555)
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Gavin Henry wrote: >> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote: >> >>> Thus I think my original report was wrong. This is a documentation >>> issue, not a bug. >> I have uploaded a suggested set of patches to make the behaviour >> clearer: >> >> ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch >> >> The patch is against 2.4.10 >> >> It might be better still to factor out the concept of proxy >> authorisation and its control from the SASL authz mechanism, as it >> applies also to the LDAP Proxied Authorization Control. >> I have not done this as I was unsure where best to put it. > > Hi Ando, > > If you get a chance at some point, could you review this patch and I'll apply it > etc. After a quick look, it seems to be a good starting point. I'd be a little bit more careful about wording: "proxyAuthz" should probably be "proxied authorization"; the first time it is mentioned, a reference to RFC4370 should be present, both in slapd.access(5) and in the Admin Guide (as in the SASL section). Also, in the contribution to the Admin Guide it is sometimes referred to as the "proxy facility"; I'd rather use "proxied authorization facility" or better "proxied authorization control". Finally, the patch seems to correctly explain what is required in order to authorize. I'd add a strong comment on the importance to protect authzFrom and especially authzTo from malicious writes, that could result in lesser privileged identities to modify their own entry in order to be able to self-authorize as higher privileged identities. Administrators should be warned as they start reading about this feature. 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#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by hyc＠symas.com 09 Feb '09

09 Feb '09

bplank(a)gta.com wrote: > Full_Name: Brad Plank > Version: 2.4.13 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch > Submission from: (NULL) (199.120.225.110) > Thanks for the report, now fixed in HEAD and RE24. > NULL pointer usage in: > LDAPConn * > ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, > int connect, LDAPreqinfo *bind ) > > ... > if ( lc->lconn_server->lud_exts ) { > ... > > The below patch is to fix this issue, since the pointer "lconn_server" should > only be used when "connect" is non-zero: > > ================================================================== > > --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 > +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 > @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > > - if ( lc->lconn_server->lud_exts ) { > -#ifdef HAVE_TLS > if ( connect ) { > +#ifdef HAVE_TLS > + if ( lc->lconn_server->lud_exts ) { > int rc, ext = find_tls_ext( lc->lconn_server ); > if ( ext ) { > LDAPConn *savedefconn; > > ================================================================== > > I, Brad Plank, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > > -- -- 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 09 Feb '09

09 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > michael(a)stroeder.com wrote: >> Such an extension would be feasible. But still I'm not sure whether this >> distinction is needed. Although LDAP URL with empty hostport portion are >> used internally (e.g. in ACLs) this IMHO does not affect >> ldap_initialize(). Maybe I missed something. But before implementing a >> patch this should be clarified. > > Do you suggest that an empty hostport (as ldap_initialize() arg) could mean > that a SRV search is needed ? > But this will reduce the search in the default domain name, won't it ? > So, how to produce a search in another specific domain name when wished ? > Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit > domain name ("my.domain") for the search domain ?... > > Secondarily, how to specify the present meaning "this LDAP server" if we use > this empty hostport syntaxe for SRV seach ? (A SRV search could respond when > the user think to request his local LDAP server ...) OpenLDAP clients do the following: empty hostport, empty DN: localhost, default port empty hostport, non-empty DN: SRV what might be missing IMHO is: use domain to specify SRV however, I don't see any special need for it, as domain can always be put in DN form. I don't know if there's need for a form that asks to use SRV to discover the server for the default SUFFIX. In order to avoid issues, I recommend using something like x-dnssrv={<domain>|<DN>} where <DN> is restricted to the domain component sequence form. 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 philippe.eychart＠informatique.gov.pf 09 Feb '09

09 Feb '09

michael(a)stroeder.com wrote: > Such an extension would be feasible. But still I'm not sure whether this > distinction is needed. Although LDAP URL with empty hostport portion are > used internally (e.g. in ACLs) this IMHO does not affect > ldap_initialize(). Maybe I missed something. But before implementing a > patch this should be clarified. Do you suggest that an empty hostport (as ldap_initialize() arg) could mean that a SRV search is needed ? But this will reduce the search in the default domain name, won't it ? So, how to produce a search in another specific domain name when wished ? Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit domain name ("my.domain") for the search domain ?... Secondarily, how to specify the present meaning "this LDAP server" if we use this empty hostport syntaxe for SRV seach ? (A SRV search could respond when the user think to request his local LDAP server ...) --- PE

1 0

(ITS#5935) segfault in syncrepl.c when replacing olcSyncrepl values by syncrepl on cn=config
by jclarke＠linagora.com 09 Feb '09

09 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS 5.2 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi all, We have encountered a segfault that occurs in syncrepl.c, on line 1449 (from a checkout of RE24 today). This occurs during replication of cn=config, by a thread in do_syncrepl on rid=999. Syncrepl pulls in new values for olcSyncRepl on cn=config. This deletes the configuration for rid=999, and adds configuration for rid=001 and rid=002. Some debugging (lots) showed the following. This thread enters syncrepl_config() 3 times: 1) Delete rid=999. This detects this syncrepl is running, and sets si->si_ctype = 0 (as described in the comments in syncrepl.c line 4358). si is not freed, since it's running. The c->be->be_syncinfo->si_cookieState is freed (line 4564). 2) Add rid=001 3) Add rid=002 Back in syncrepl.c on line 1449, the "final delete cleanup" looks for it's own si in be->be_syncinfo. It of course doesn't find it (the config is deleted), and segfaults when sip = null. We have tried changing these lines to: for ( sip = &be->be_syncinfo; sip != NULL || *sip != si; sip = &(*sip)->si_next ); if (sip) { *sip = si->si_next; } However, we then encounter another segfault on line 1448, involving be->be_syncinfo->si_cookieState, which was freed... It's a bit too much for us at this point, do you have any more ideas?

1 0

(ITS#5934) NULL pointer usage in ldap_new_connection(), causes segmentation fault
by bplank＠gta.com 09 Feb '09

09 Feb '09

Full_Name: Brad Plank Version: 2.4.13 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/brad-plank-090209.patch Submission from: (NULL) (199.120.225.110) NULL pointer usage in: LDAPConn * ldap_new_connection( LDAP *ld, LDAPURLDesc **srvlist, int use_ldsb, int connect, LDAPreqinfo *bind ) ... if ( lc->lconn_server->lud_exts ) { ... The below patch is to fix this issue, since the pointer "lconn_server" should only be used when "connect" is non-zero: ================================================================== --- libraries/libldap/request.c.orig 2008-11-07 20:15:17.000000000 -0500 +++ libraries/libldap/request.c 2009-02-09 11:01:56.000000000 -0500 @@ -452,9 +452,9 @@ ldap_new_connection( LDAP *ld, LDAPURLDe ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif - if ( lc->lconn_server->lud_exts ) { -#ifdef HAVE_TLS if ( connect ) { +#ifdef HAVE_TLS + if ( lc->lconn_server->lud_exts ) { int rc, ext = find_tls_ext( lc->lconn_server ); if ( ext ) { LDAPConn *savedefconn; ================================================================== I, Brad Plank, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Yes, I confirm that now the slapd from HEAD simply ignores the intermediate response type. So I can go forward on my projet :-) In this project I do not bother about the contextCSN of my replica because it is managed by another master. Thanks a lot for this rapid fix. Best Regards Ali Selon Pierangelo Masarati <ando(a)sys-net.it>: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. > > p.

1 0

Re: (ITS#5930) Problem while making the build
by quanah＠zimbra.com 09 Feb '09

09 Feb '09

--On Monday, February 09, 2009 7:44 AM +0000 bhupi.iit(a)gmail.com wrote: > Full_Name: Bhupinder > Version: 2.4.11 > OS: Solaris SunOS.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.167.165) > > > setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib > setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ > > ./configure > make depend > make > > while 'mak'ing i get the following error. > .. > .. > .. > /bin/sh ../..//libtool --mode=compile cc -g -I../../include > -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c > tls.c cc -g -I../../include -I../../include > -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o > .libs/tls.o > "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t > "tls.c", line 112: syntax error before or at: typedef > "tls.c", line 114: syntax error before or at: > gnutls_certificate_credentials_t "tls.c", line 127: syntax error before > or at: typedef > "tls.c", line 128: syntax error before or at: tls_ctx > "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free > "tls.c", line 189: warning: syntax requires ";" after last struct/union > member "tls.c", line 189: syntax error before or at: { > "tls.c", line 191: syntax error before or at: tls_ctx > "tls.c", line 211: member cannot be function: tls_ctx_new > "tls.c", line 211: warning: syntax requires ";" after last struct/union > member "tls.c", line 211: syntax error before or at: { > "tls.c", line 230: syntax error before or at: * > "tls.c", line 231: member cannot be function: tls_ctx_ref > "tls.c", line 231: warning: syntax requires ";" after last struct/union > member "tls.c", line 242: warning: syntax requires ";" after last > struct/union member "tls.c", line 262: warning: syntax requires ";" after > last struct/union member "tls.c", line 275: syntax error before or at: * > "tls.c", line 276: member cannot be function: tls_session_free > "tls.c", line 276: warning: syntax requires ";" after last struct/union > member "tls.c", line 285: syntax error before or at: * > "tls.c", line 285: warning: undefined or missing type for: char > "tls.c", line 286: member cannot be function: tls_parse_ciphers > "tls.c", line 286: warning: syntax requires ";" after last struct/union > member "tls.c", line 289: warning: syntax requires ";" after last > struct/union member "tls.c", line 289: syntax error before or at: = > "tls.c", line 292: syntax error before or at: num > "tls.c", line 314: warning: syntax requires ";" after last struct/union > member "tls.c", line 350: zero-sized struct/union > "tls.c", line 352: warning: old-style declaration or incorrect type for: > ptr "tls.c", line 352: warning: old-style declaration or incorrect type > for: len "tls.c", line 352: warning: syntax error: empty declaration > "tls.c", line 353: warning: old-style declaration or incorrect type for: > end "tls.c", line 354: undefined symbol: nkx > "tls.c", line 354: can not declare variably modified type at file scope > "tls.c", line 354: warning: old-style declaration or incorrect type for: > kx "tls.c", line 354: warning: {}-enclosed initializer required > "tls.c", line 354: too many array initializers > "tls.c", line 354: warning: variable length array can not be initialized: > kx "tls.c", line 355: undefined symbol: ncipher > "tls.c", line 355: can not declare variably modified type at file scope > "tls.c", line 355: warning: old-style declaration or incorrect type for: > cipher "tls.c", line 355: warning: {}-enclosed initializer required > "tls.c", line 355: too many array initializers > "tls.c", line 355: warning: variable length array can not be initialized: > cipher > "tls.c", line 356: undefined symbol: nmac > "tls.c", line 356: can not declare variably modified type at file scope > "tls.c", line 356: warning: old-style declaration or incorrect type for: > mac "tls.c", line 356: warning: {}-enclosed initializer required > "tls.c", line 356: too many array initializers > "tls.c", line 356: warning: variable length array can not be initialized: > mac "tls.c", line 357: warning: old-style declaration or incorrect type > for: ctx "tls.c", line 357: syntax error before or at: -> > "tls.c", line 357: warning: old-style declaration or incorrect type for: > kx_list > "tls.c", line 357: warning: improper pointer/integer combination: op "=" > "tls.c", line 358: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 358: syntax error before or at: -> > "tls.c", line 358: warning: old-style declaration or incorrect type for: > cipher_list > "tls.c", line 358: warning: improper pointer/integer combination: op "=" > "tls.c", line 359: warning: old-style declaration or incorrect type for: > ctx "tls.c", line 359: syntax error before or at: -> > "tls.c", line 359: warning: old-style declaration or incorrect type for: > mac_list > "tls.c", line 359: warning: improper pointer/integer combination: op "=" > "tls.c", line 360: syntax error before or at: return > "tls.c", line 360: warning: syntax error: empty declaration > "tls.c", line 532: cannot recover from previous errors > cc: acomp failed for tls.c > make[2]: *** [tls.lo] Error 1 > make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' > make: *** [all-common] Error 1 > > > > Please let me know if i'm doing something wrong here. Looks like it can't find your GnuTLS headers/libs, at a guess. In any case, this isn't an OpenLDAP bug. Please use openldap-software for further help with building OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ando(a)sys-net.it wrote: > Slapd in HEAD no longer crashes when receiving intermediate response. > It rather complains about an unsupported response message. I'm now > working at correctly handling it. This won't probably be as easy as I expected: back-meta does not check, parse or return entry controls. This needs to be fixed as well. I notice that back-ldap and back-meta use ldap_first_entry() to parse the entry. Syncrepl client-side code uses a ldap_get_entry_controls() and explicit entry parsing. Probably we need to abstract what syncrepl does in a new libldap call that parses an entry and its controls, and use it as appropriate. 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

Need bug list for openldap-2.2.24 release.
by kalyan tej 09 Feb '09

09 Feb '09

Hi Folks, I am new to openldap ,I'd like to know the list of software bugs in openldap-2.2.24 release. I chose openldap-2.2.24 because my libc version is 2.3.3.It would be of great help to me if someone can provide me with the major list of bugs in the mentioned release and/or fixes . Thanks in advance, -Kalyan Tej

2 1

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

Slapd in HEAD no longer crashes when receiving intermediate response. It rather complains about an unsupported response message. I'm now working at correctly handling it. 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#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 09 Feb '09

09 Feb '09

ali.pouya(a)free.fr wrote: > I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd > through an intermediate back-meta slapd in order tu use its RWM features. > The search entries are propagated without problem. But back-meta crashes each > time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider > reproducing the following message : > > read1msg: ld 0x9f29550 msgid 2 message type intermediate > slapd: search.c:1460: meta_back_search: Assertion `0' failed. > Abandon Back-beta (and probably back-ldap) need to be able to recognize intermediate response messages, as they are part of the protocol. Probably, it would be a good idea to detect unrecognized response messages and handle them nicely. > I think this would be a useful feature to be able to make replicas that are > different from the master. > May be if this response time is propagated as is this type of synchronization > will be possible ? I'd notice that this type of operation might be less than ideal, since a proxied refreshAndPersist operation will keep one thread of the proxy busy all times waiting for further responses. > I am aware that connection to more thant one targets through back-meta may be > meaningless. In that case you could use back-ldap with slapo-rwm. 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#5933) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5932) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

(ITS#5931) back-meta crashes with syncrepl data
by ali.pouya＠free.fr 09 Feb '09

09 Feb '09

Full_Name: Ali Pouya Version: 2.4.13 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I try to connect a RefreshAndPersist syncrepl client to a sync provider slapd through an intermediate back-meta slapd in order tu use its RWM features. The search entries are propagated without problem. But back-meta crashes each time it receives the LDAP_RES_INTERMEDIATE response time from the sync provider reproducing the following message : read1msg: ld 0x9f29550 msgid 2 message type intermediate slapd: search.c:1460: meta_back_search: Assertion `0' failed. Abandon I think this would be a useful feature to be able to make replicas that are different from the master. May be if this response time is propagated as is this type of synchronization will be possible ? I am aware that connection to more thant one targets through back-meta may be meaningless. Thanks for your help Best Redgards Ali Pouya

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 09 Feb '09

09 Feb '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>>> Seems to me we need to reinstate those commands. >>> Fixed now in HEAD >> Didn't help. But I'm not sure it was necessary anyway - after all it >> did find the libraries when I did not set LDPATH, even though there >> were no symlinks. Something is being quite magical. >> > Eh. I'd forgotten. The libtool script generates a wrapper script for each > binary that sets LD_LIBRARY_PATH already. So really we should remove the > LD_LIBRARY_PATH export from scripts/defines.sh. > > And that means your problem is a libtool problem. I played with this a bit more. The situation is this: The ELF linker doesn't store the absolute pathnames of dependent dynamic libraries, so it relies entirely on compiled-in runpaths and environment runpaths. Our default invocations of libtool never supply a runpath. Since you're adding one explicitly to your build, without any other settings, your runpath is the only one in effect. Since you're setting both -L and -rpath, your binaries will be linked and executed against your installed libs, regardless of what the libtool wrapper script does. If you want this to work you'll have to provide both the build directory and your installed directory in your -rpath. The symlinks would then help a little, because you only need to set one build rpath instead of 3. Go ahead and restore the build rules in your source tree to set the symlinks if you want them. At the moment it looks like they're not generally useful, and I'm tired of committing/reverting, so I'm not touching those files any more today. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> Seems to me we need to reinstate those commands. >> Fixed now in HEAD > > Didn't help. But I'm not sure it was necessary anyway - after all it > did find the libraries when I did not set LDPATH, even though there > were no symlinks. Something is being quite magical. > Eh. I'd forgotten. The libtool script generates a wrapper script for each binary that sets LD_LIBRARY_PATH already. So really we should remove the LD_LIBRARY_PATH export from scripts/defines.sh. And that means your problem is a libtool problem. -- -- 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

(ITS#5930) Problem while making the build
by bhupi.iit＠gmail.com 08 Feb '09

08 Feb '09

Full_Name: Bhupinder Version: 2.4.11 OS: Solaris SunOS.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.77.167.165) setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB/lib setenv CPPFLAGS -I/usr/local/BerkeleyDB/include/ ./configure make depend make while 'mak'ing i get the following error. .. .. .. /bin/sh ../..//libtool --mode=compile cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c cc -g -I../../include -I../../include -I/usr/local/BerkeleyDB/include/ -DLDAP_LIBRARY -c tls.c -KPIC -DPIC -o .libs/tls.o "tls.c", line 102: syntax error before or at: gnutls_kx_algorithm_t "tls.c", line 112: syntax error before or at: typedef "tls.c", line 114: syntax error before or at: gnutls_certificate_credentials_t "tls.c", line 127: syntax error before or at: typedef "tls.c", line 128: syntax error before or at: tls_ctx "tls.c", line 189: member cannot be function: ldap_pvt_tls_ctx_free "tls.c", line 189: warning: syntax requires ";" after last struct/union member "tls.c", line 189: syntax error before or at: { "tls.c", line 191: syntax error before or at: tls_ctx "tls.c", line 211: member cannot be function: tls_ctx_new "tls.c", line 211: warning: syntax requires ";" after last struct/union member "tls.c", line 211: syntax error before or at: { "tls.c", line 230: syntax error before or at: * "tls.c", line 231: member cannot be function: tls_ctx_ref "tls.c", line 231: warning: syntax requires ";" after last struct/union member "tls.c", line 242: warning: syntax requires ";" after last struct/union member "tls.c", line 262: warning: syntax requires ";" after last struct/union member "tls.c", line 275: syntax error before or at: * "tls.c", line 276: member cannot be function: tls_session_free "tls.c", line 276: warning: syntax requires ";" after last struct/union member "tls.c", line 285: syntax error before or at: * "tls.c", line 285: warning: undefined or missing type for: char "tls.c", line 286: member cannot be function: tls_parse_ciphers "tls.c", line 286: warning: syntax requires ";" after last struct/union member "tls.c", line 289: warning: syntax requires ";" after last struct/union member "tls.c", line 289: syntax error before or at: = "tls.c", line 292: syntax error before or at: num "tls.c", line 314: warning: syntax requires ";" after last struct/union member "tls.c", line 350: zero-sized struct/union "tls.c", line 352: warning: old-style declaration or incorrect type for: ptr "tls.c", line 352: warning: old-style declaration or incorrect type for: len "tls.c", line 352: warning: syntax error: empty declaration "tls.c", line 353: warning: old-style declaration or incorrect type for: end "tls.c", line 354: undefined symbol: nkx "tls.c", line 354: can not declare variably modified type at file scope "tls.c", line 354: warning: old-style declaration or incorrect type for: kx "tls.c", line 354: warning: {}-enclosed initializer required "tls.c", line 354: too many array initializers "tls.c", line 354: warning: variable length array can not be initialized: kx "tls.c", line 355: undefined symbol: ncipher "tls.c", line 355: can not declare variably modified type at file scope "tls.c", line 355: warning: old-style declaration or incorrect type for: cipher "tls.c", line 355: warning: {}-enclosed initializer required "tls.c", line 355: too many array initializers "tls.c", line 355: warning: variable length array can not be initialized: cipher "tls.c", line 356: undefined symbol: nmac "tls.c", line 356: can not declare variably modified type at file scope "tls.c", line 356: warning: old-style declaration or incorrect type for: mac "tls.c", line 356: warning: {}-enclosed initializer required "tls.c", line 356: too many array initializers "tls.c", line 356: warning: variable length array can not be initialized: mac "tls.c", line 357: warning: old-style declaration or incorrect type for: ctx "tls.c", line 357: syntax error before or at: -> "tls.c", line 357: warning: old-style declaration or incorrect type for: kx_list "tls.c", line 357: warning: improper pointer/integer combination: op "=" "tls.c", line 358: warning: old-style declaration or incorrect type for: ctx "tls.c", line 358: syntax error before or at: -> "tls.c", line 358: warning: old-style declaration or incorrect type for: cipher_list "tls.c", line 358: warning: improper pointer/integer combination: op "=" "tls.c", line 359: warning: old-style declaration or incorrect type for: ctx "tls.c", line 359: syntax error before or at: -> "tls.c", line 359: warning: old-style declaration or incorrect type for: mac_list "tls.c", line 359: warning: improper pointer/integer combination: op "=" "tls.c", line 360: syntax error before or at: return "tls.c", line 360: warning: syntax error: empty declaration "tls.c", line 532: cannot recover from previous errors cc: acomp failed for tls.c make[2]: *** [tls.lo] Error 1 make[2]: Leaving directory `~openldap/openldap-2.4.11/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `~/openldap/openldap-2.4.11/libraries' make: *** [all-common] Error 1 Please let me know if i'm doing something wrong here. Thanks bhupi

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 08 Feb '09

08 Feb '09

hyc(a)symas.com writes: >> Seems to me we need to reinstate those commands. > > Fixed now in HEAD Didn't help. But I'm not sure it was necessary anyway - after all it did find the libraries when I did not set LDPATH, even though there were no symlinks. Something is being quite magical. -- Hallvard

1 0

Re: (ITS#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

hyc(a)symas.com wrote: > Hmm. The export in defines.sh is useless now, because build/lib-shared.mk's > rules to symlink the shared libraries into place was removed in rev 1.16. > > (See the lib-shared/mk CVS log...) > > Seems to me we need to reinstate those commands. > Fixed now 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

hyc(a)symas.com wrote: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>>> "make test" uses installed instead of newly built libraries, >>>> with ./configure --enable-dynamic LDFLAGS=<installed lib>. >>> Don't do that. >> Then what do I do? Some libraries OpenLDAP needs are there, including >> DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's >> DB 4.3, so configure doesn't magically look in<--prefix>/lib/ on its >> own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. >> >> I don't want to require $LD_LIBRARY_PATH to be set before running >> OpenLDAP programs, nor to mess with /etc/ld.so.conf. > > Note that scripts/defines.sh already explicitly sets LD_LIBRARY_PATH to point > at the newly built libraries. What else do you expect us to do? > Hmm. The export in defines.sh is useless now, because build/lib-shared.mk's rules to symlink the shared libraries into place was removed in rev 1.16. (See the lib-shared/mk CVS log...) Seems to me we need to reinstate those commands. -- -- 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#5927) assertion error when using pcache
by hyc＠symas.com 08 Feb '09

08 Feb '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> As an alternative, I suggest modifying slapd/ad.c to treat "=" the same as "-" >> in an option definition. Then simply adding >> attributeoption range= >> to slapd.conf will allow the values to be recognized. (With the constraint >> that '=' must be the final character in the option definition...) >> >> Let the client decide if they want to go thru the trouble of retrieving all >> the values or not. Certainly, for slapd to do it implicitly will overburden >> the (pathetically broken) AD server (otherwise they wouldn't need to break the >> value up into ranges in the first place). Indeed, doing this implicitly would >> amount to a DOS attack on the AD server. > > I strongly agree with Howard here. The work-around for "=" seems enough. > If someone really writes an app which needs the range feature it should > access AD directly. Right. This is now changed in HEAD. If an attributeoption is configured that ends with '=' then MSAD compatibility is enabled, otherwise '=' is rejected as usual. -- -- 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#5929) 'make test' uses installed libldap_r/liblber
by hyc＠symas.com 08 Feb '09

08 Feb '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> "make test" uses installed instead of newly built libraries, >>> with ./configure --enable-dynamic LDFLAGS=<installed lib>. >> Don't do that. > > Then what do I do? Some libraries OpenLDAP needs are there, including > DB 4.4. Without LDFLAGS and corresponding CPPFLAGS I get the system's > DB 4.3, so configure doesn't magically look in<--prefix>/lib/ on its > own. Or with CPPFLAGS but without LDFLAGS I get DB version mismatch. > > I don't want to require $LD_LIBRARY_PATH to be set before running > OpenLDAP programs, nor to mess with /etc/ld.so.conf. Note that scripts/defines.sh already explicitly sets LD_LIBRARY_PATH to point at the newly built libraries. What else do you expect us to do? -- -- 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#5927) assertion error when using pcache
by ando＠sys-net.it 08 Feb '09

08 Feb '09

mhardin(a)symas.com wrote: >> mhardin(a)symas.com wrote: >>> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>>> mhardin(a)symas.com wrote: >>>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>>> what I >>>>> find. >>>> No problem. Note that if this is the cause of this issue, and, in >>>> any >>>> case, if you have some "range" attributes in your response, you >>>> still >>>> have an issue with those values. >>> Yes. I'm not sure what to do about them in the medium term. Not >>> having slapd crash is a good first step, though :P >> Are you confirming that the original issue is fixed? > > Unfortunately not. The morning I tested the fix you checked into HEAD > and still got an assertion error in pcache at the same point when > caching group objects that contain range specifiers. I have core files > and would be happy to provide additional information if you need it. As I wrote, I only simulated receiving that type of response by modifying the name of the attribute after it was extracted by back-meta and before it was resolved. It would be interesting to see what happens when the actual response of AD is received by back-meta. In any case, since you have the core files, it would be interesting to see the attribute structure, and specifically of the a_desc member (the AttributeDescription structure). 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#5927) assertion error when using pcache
by mhardin＠symas.com 08 Feb '09

08 Feb '09

On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> On Feb 7, 2009, at 9:21 AM, ando(a)sys-net.it wrote: >>> mhardin(a)symas.com wrote: >>>> Sorry for the out-of-sequence reply. I'll test and let you know >>>> what I >>>> find. >>> No problem. Note that if this is the cause of this issue, and, in >>> any >>> case, if you have some "range" attributes in your response, you >>> still >>> have an issue with those values. >> Yes. I'm not sure what to do about them in the medium term. Not >> having slapd crash is a good first step, though :P > > Are you confirming that the original issue is fixed? Unfortunately not. The morning I tested the fix you checked into HEAD and still got an assertion error in pcache at the same point when caching group objects that contain range specifiers. I have core files and would be happy to provide additional information if you need it. > > >>> It seems that, in the spirit of >>> OpenLDAP software, we could be relatively liberal in accepting those >>> values provided we are able to consolidate them in a single entry >>> with >>> no ranges. Apparently, what the proxies could do is: >>> >>> - whenever a range is obtained in a response >>> - iteratively query the server again for the same entry, >>> - requesting only that attribute for the next block of vals >>> - incrementally build the set of values >>> - return the consolidated entry >>> >>> This MUST be configurable, and documented as a nasty, expensive and >>> unnecessary hack. >>> >> I had thought it might be possible to craft this functionality as >> an overlay (we could call it "derange" :P), but I think you're >> right- it is more appropriate that it be something configurable in >> back-meta and back-ldap. > > You can't handle that with an overlay, since the message containing > this type of response is received by the proxy backends and would > fail parsing unless handled there :). So I've learned :) > > >> This functionality is particularly interesting when one considers >> using Howard's nss_ov in conjunction with pcache and back- ldap >> communicating with directory servers that were never intended to >> handle the high loads that Unix/Linux name services can place on a >> directory server ;-) >> The high cost of the iterative searches might be mitigated through >> use of pcache. I'm thinking the searches to consolidate the >> ranged attributes would happen anyway, so better to do them in the >> proxy and cache the results than make each individual client have >> to do them. > > Yes. Another possible issue is that we'd probably need to work a > symmetric solution in those cases where a request needs values to be > broken in ranges in order to be accepted by AD. Ugh. I suppose so, although my interest in that is relatively low at this point. > > > p. > > -Matt > 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs