openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Start a nNew thread

Re: (ITS#6150) schema compliance checking tool
by masarati＠aero.polimi.it 28 May '09

28 May '09

Added to HEAD. Please test. p.

1 0

(ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.68.118) masarati(a)aero.polimi.it wrote: > Comes to mind that something like a schema compliance checking tool, > either off- or on-line could be useful. Sort of a "slapschema" that > checks the schema compliance of each entry (matching a filter or > within a subtree specification) in a given database. The result could contain the DNs of non-compliant entries each with the diagnostic message which would have been returned to a client adding such a non-compliant entry.

1 0

(ITS#6149) ldapsearch is not really script-friendly (patch included)
by bugreporter＠udmvt.ru 28 May '09

28 May '09

Full_Name: Alexey Version: 2.4.15 (LDAP library: OpenLDAP 20415) OS: Debian GNU/Linux URL: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch Submission from: (NULL) (78.85.1.13) Good day, everyone. ldapsearch have such important (mis)feature, like output format conforming to LDIF standard in some or other way. You should already know, that line length in LDIF-output is limited to 76 characters and if line is larger, it is wrapped with space-padding. Also output is sometimes base64 encoded, based on it's "printability". Printability is tested, using single-byte functions, like isgraph(), but when values is multibyte encoded with UTF-8, that sometimes produce random results. That together makes ldapsearch very script-unfriendly and here is why: to limit randomness in output's encoding, one would use -tt switch to always write field values to files and then use some simple script to parse the output and substitute file urls with their contents. But here comes to play line length limit, that will sometimes wrap urls for fields with long names (that is common for AD). Here is example: msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-ZhHdx2 msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-c4gGc1 msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-FM UbSZ msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-6bLIxY End of example. That introduces extra unneeded complexity in otherwise simple script, since now it should parse LDIF, combine whole lines from broken ones, etc. Making it no longer an one-line script. Since wrapping of -tt output is nonsense, but changing that may seem unfeasible for some of you, let me suggest additional option -ttt, that does the same as -tt, but without line wrapping (perhaps, violating some standard). Patch is here, as your ITS asks: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch PS: manpage does not changed to reflect additional option Thanks a lot.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 28 May '09

28 May '09

--=-0SnOgocYLpYqWd2pGoMe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. >=20 > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Hmm. Using that KVM image, with the libsasldb moved aside (and with it left in place), I still get errors. =20 However, there is an important difference: Where previously, once it locked up nothing proceeded, now it proceeds - as if the failure is temporary now. The error has changed too - instead of a failure to connect, it is an inability to successfully read the rootDSE.=20 I agree, we might be jumping at different shadows here, but your patches did fix something... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-0SnOgocYLpYqWd2pGoMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHeuvz4A8Wyi0NrsRAoaGAJ9olpo9+ni006pt9kK5CkXJObYNCQCgorgP DswBOLRtdrlhFHibmX4XrC4= =bjw6 -----END PGP SIGNATURE----- --=-0SnOgocYLpYqWd2pGoMe--

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> The send_ldap_response() fix is still incomplete: [Reversing the quoteed message] >> Also, this: >> rc = rs->sr_err; >> if ( rc == SLAPD_ABANDON&& op->o_cancel ) >> rc = LDAP_CANCELLED; >> will send a negative result code (SLAPD_ABANDON) if !o_cancel. > > No, it won't. That is all bypassed at the top of the function. If so, the quoted op->o_cancel test could be skipped. But an overlay could set rs->sr_err = SLAPD_ABANDON during slap_response_play(). Though that ought to mean o_abandon is set, so send_ldap_ber() will drop the message. So you're right after all that it won't be sent. >> Note, not just when the function itself sets rc = LDAP_CANCELLED, >> since syncprov can set rs->sr_err = LDAP_CANCELLED too. >> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when >> sr_ref != NULL is rather dubious. Maybe sr_ref should just >> be ignored when sending something else than LDAP_REFERRAL. > > Leave the assert() in place until you have proof one way or the other. Haven't tested with an example of an overlay setting SLAPD_ABANDON; could check syncprov or retcode I suppose. Faked it with nanosleep(&((struct timespec){0,2E8}), 0); /*gcc or C99 code*/ if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON; after the op->o_callback->sc_response in slap_response_play(). Then, with this slapd.conf: include servers/slapd/schema/core.schema referral ldap://elsewhere/ database frontend overlay valsort send Delete "cn=urgle" <wait 0.1 second> Abandon <previous request> lt-slapd: result.c:479: send_ldap_response: Assertion `rs->sr_err == 0x0a' failed. One more detail, looking at result.c rev 1.330 send_ldap_response(): I presume the LDAP_CONNECTIONLESS branch should also ber_printf rc rather than rs->sr_err to the response. Not sure if Cancel makes sense in cldap (and after V2 Bind which has no extended operation at that), but OpenLDAP does let through Cancel after a V2 Bind. >> When rc == LDAP_CANCELLED, the function should not send sr_matched, >> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems >> slap_cleanup_play() should still see them if they are not sent? > > Dunno what you mean. I thought that was obvious, but since it isn't maybe I should ask ldapext instead. Cancel does seem underspecified in this regard. Anyway, I meant: Either an operation gets cancelled/abandoned, or it doesn't and comletes. If these fields are set, they most likely relate to a completed operation. Nowhere SLAPD_ABANDON gets set, are the others set - possibly except with back-meta/back-ldap, I haven't looked too closely. OTOH, code setting SLAPD_ABANDON rarely _clears_ those fields, so I imagine they can convey information which would have been removed (access controls maybe?) or updated before they were sent, if the operation had completed. Clearing a critical control can be a bit doubtful, I'll grant. But for not obeying critical controls it's a choice between which error code to return - unavailableCriticalExtension, cancelled, or something else. Or some controls could mark the operation as "uncancellable" (another flag needed...) But come to think of it, an Extended Response has some of the same problem. By the above reasoning, responseName and responseValue should be dropped in a Cancelled response, as when sending protocolError to an unrecognized reqest. Might be a bit extreme. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 27 May '09

27 May '09

Hallvard B Furuseth wrote: > The send_ldap_response() fix is still incomplete: > > When rc == LDAP_CANCELLED, the function should not send sr_matched, > sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems > slap_cleanup_play() should still see them if they are not sent? Dunno what you mean. > Note, not just when the function itself sets rc = LDAP_CANCELLED, > since syncprov can set rs->sr_err = LDAP_CANCELLED too. > Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when > sr_ref != NULL is rather dubious. Maybe sr_ref should just > be ignored when sending something else than LDAP_REFERRAL. Leave the assert() in place until you have proof one way or the other. > Also, this: > rc = rs->sr_err; > if ( rc == SLAPD_ABANDON&& op->o_cancel ) > rc = LDAP_CANCELLED; > will send a negative result code (SLAPD_ABANDON) if !o_cancel. No, it won't. That is all bypassed at the top of the function. -- -- 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#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

The send_ldap_response() fix is still incomplete: When rc == LDAP_CANCELLED, the function should not send sr_matched, sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems slap_cleanup_play() should still see them if they are not sent? Note, not just when the function itself sets rc = LDAP_CANCELLED, since syncprov can set rs->sr_err = LDAP_CANCELLED too. Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when sr_ref != NULL is rather dubious. Maybe sr_ref should just be ignored when sending something else than LDAP_REFERRAL. Also, this: rc = rs->sr_err; if ( rc == SLAPD_ABANDON && op->o_cancel ) rc = LDAP_CANCELLED; will send a negative result code (SLAPD_ABANDON) if !o_cancel. I guess it should be if ( rc == SLAPD_ABANDON ) { if ( !op->o_cancel ) goto <cleanup or clean2>; rc = LDAP_CANCELLED; } While we're at it, I suggest to generalize this to avoid sending result codes < 0. Send LDAP_OTHER instead. That's ITS#5328 again. -- Hallvard

1 0

Re: (ITS#6108) unique overlay and rootdn
by hyc＠symas.com 27 May '09

27 May '09

mfn(a)fs-etit.de wrote: > Full_Name: Christopher Dyck > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.83.183.3) > > > I found a strange behavior in the unique overlay. > > unique overlay only works, when a rootdn is specified in the slapd.conf, because > the unique_search function uses the rootdn for searching. (took me hours to > determine why my configuration didn't do it's job) > > Isn't it more reasonable to use the dn with which the add or modify is > performed? Definitely not. The user performing the write may not have sufficient access to see all of the instances of the attribute in question. > Or mention this circumstance at least in the manpage?! Probably. -- -- 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#6141 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6141 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6141

1 0

ITS#6143 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6143 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6143

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