- openldap-bugs - openldap.org

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >>Howard Chu writes: >>>> Both RFCs disagree. >>> >>> They are wrong. Or at least, under-specified. In X.501 section 17.3 >>> "Directory Distribution Model" it's quite clear that all of the >>> components of a distributed directory must belong to a single DIT. >> >> Which is not true in the LDAP world, and I don't know about today's >> X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe >> the X.500 world has also switched to 'dc' structure, I don't know. >> >> Anyway, LDAP is not X.500. > > RFC4510 Section 2 "Relationship to X.500" > (...) An LDAP server MUST act in accordance with the X.500 (1993) > series (...) Except when it doesn't. Like the various implications of sending text instead of ASN.1 and numeric OIDs. > (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 > it's clear that nobody knew what they were doing, or nobody wanted to > tackle the glaring absence of an analogue to X.500 DSP. LDAPv2 (the standard) has no referrals. The Umich implementation introduced them as a hack: It stuffed them into the errorMessage field. LDAPv3 moved them into the standard. And speaking for my own little corner of the standardization process, I definitly was ignorant about them and wanted nothing to do with them. I've still never had any use for LDAP referrals. > They should never have been introduced. We're stuck with them for > now, but we can at least try to make them make sense. Well, take it up with ldapext. And add an option to slapd to reject attempts to add 'ref' attrs with a DN, or whatever. For now, once the directory contains a 'ref' URL which includes the DN, I don't see any reason not to rewrite like the spec says. Whatever the "right answer" is, a referral with an un-rewritten DN seems worse than with a rewritten one. Regarding the branches of bdb_referrals() and ldif_back_referrals() which rewrite default_referral: I suggest we delete it. The back-ldif code breaks exactly as one would expect: With referral ldap://urgle/ database ldif suffix o=foo and an empty database, ldapcompare cn=bar,o=foo gives a referral to urgle. So does ldapadd of o=foo:-( I seem to remember someone meant the latter was correct and there was a control to prevent it at some point, maybe that is related. back-bdb has a test which prevents this referral in case of the suffix dn, but not for superior DNs. But I don't see why it would not be just as buggy for superiors, if it could happen. -- Hallvard

1 0

Re: (ITS#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

hyc(a)symas.com writes: > One thing that I've started doing recently in my configs is to skip > the #bytes option (leave it zero), so that only time-based checkpoints > occur. Since they're done in a dedicated task, only one thread at a > time can trigger a checkpoint. How about making #bytes-based checkpoints signal or (pthread_kill?) the timed checkpoints thread, so that thread can handle all checkpoints? -- Hallvard

1 0

(ITS#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by toby＠inf.ed.ac.uk 07 Mar '08

07 Mar '08

Full_Name: Toby Blake Version: 2.3.38 amd 2.3.40 OS: Fedora Core 5 and Fedora Core 6 URL: Submission from: (NULL) (129.215.218.33) Hi there, We're seeing a (seemingly) intermittent problem when using back-ldap (with or without using the pcache overlay for caching), where 1 in x queries fail with "result: 80 Internal (implementation specific) error", where x is anywhere between 2 and 10. We're seeing this with both openldap-2.3.38 and openldap-2.3.40 - running on Fedora Core 5 and 6. The remote server is running FC5, openldap 2.3.38. I currently have a machine exhibiting this problem - it's a machine in a student lab. The database part of slapd.conf on this machine is: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/inganoust.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri ldap://testdir.inf.ed.ac.uk/ idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" I'm afraid I can't currently reproduce this error, but hopefully some of the information below will help... I've done some stepping through the code and what seems to be happening when the error occurs is that the call to getpeername in ldap_host_connected_to in libraries/libldap/os-ip.c:590 fails with errno=107 "transport endpoint is not connected" and thereafter ldap_int_sasl_open (cyrus.c:518) is called with NULL as the 'host' argument (in our case it should be 'hadrian.inf.ed.ac.uk') - this results in LDAP_LOCAL_ERROR being returned. The backtrace (in ldap_host_connected_to) is: (gdb) bt #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") at os-ip.c:586 #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at cyrus.c:643 #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) at bind.c:1997 #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) at search.c:166 #5 0x0806317f in fe_op_search (op=0x8952900, rs=0xb370f1c4) at search.c:355 #6 0x08063b31 in do_search (op=0x8952900, rs=0xb370f1c4) at search.c:217 #7 0x08061209 in connection_operation (ctx=0xb370f238, arg_v=0x8952900) at connection.c:1133 #8 0x081322f3 in ldap_int_thread_pool_wrapper (xpool=0x88a1d18) at tpool.c:478 #9 0x00db145b in start_thread () from /lib/libpthread.so.0 #10 0x001cf23e in clone () from /lib/libc.so.6 (gdb) When getpeername returns the error, it is always for the same 'sd' value - on the machine I'm looking at, it's 13, e.g. 590 if ( getpeername( sd, sa, &len ) == -1 ) { (gdb) p sd $3 = 13 (gdb) p errno $4 = 107 (gdb) What's interesting here is that if I use lsof to see the filehandles that slapd is holding open, I see this for FD 13: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 2551 ldap 13u sock 0,5 3603708 can't identify protocol Interestingly, this is the exact same output I see from lsof if a socket() has been created, but not connect()ed. It appears then, that a socket of this type gets into the pool of connections to the remote server being used by the local slapd, thus explaining the 1 in x failure rate - as it cycles through the pool. I currently have a machine in this state, so if there's more information I could usefully provide, then let me know. I can of course change the loglevel, but that would involve restarting slapd on this machine - which fixes the problem. Anyway, let me know if there's more I can do - I can experiment on other machines. Cheers Toby Blake School of Informatics University of Edinburgh

1 0

Re: (ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

More detail in "private" ITS#3864. -- Hallvard

1 0

(ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by rein＠basefarm.no 07 Mar '08

07 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Below is a patch that fixes, or more correctly works around, a 64bit bug in servers/slapd/syncrepl.c that causes a bus error on (at least) 64bit Solaris. The real problem is imho that libraries/libldap/cyrus.c expects the argument where it should write the LDAP_OPT_X_SASL_* options to be of type ber_len_t and not the sasl_*_t type matching the option value it returns. I.e, the pointer variable where the returns values are written should be cast to the appropriate sasl_*_t type, not a ber_len_t. Writing to a 64bit ber_len_t when the argument is a 32bit sasl_ssf_t causes an alignment error at best case, memory corruption at worst. I haven't looked too deeply into other cases where LDAP_OPT_X_SASL_* options are set or retrieved with ldap_set_option() or ldap_get_option(), so I don't know the consequence of changing cyrus.c. That's why I don't have what I would consider a real fix to libraries/libldap/cyrus.c rather than this workaround. Rein Tollevik Basefarm AS Index: servers/slapd/syncrepl.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.18 diff -u -u -w -r1.1.1.18 syncrepl.c --- servers/slapd/syncrepl.c 21 Feb 2008 13:55:21 -0000 1.1.1.18 +++ servers/slapd/syncrepl.c 7 Mar 2008 11:34:08 -0000 @@ -444,6 +444,10 @@ #ifdef HAVE_TLS void *ssl; #endif + ber_len_t ssf; /* XXX The correct type would be sasl_ssf_t, but + * this is what the LDAP_OPT_X_SASL_SSF return + * value is cast into in libldap/cyrus.c + */ rc = slap_client_connect( &si->si_ld, &si->si_bindconf ); if ( rc != LDAP_SUCCESS ) { @@ -462,7 +466,8 @@ op->o_tls_ssf = ldap_pvt_tls_get_strength( ssl ); } #endif /* HAVE_TLS */ - ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &op->o_sasl_ssf ); + ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &ssf); + op->o_sasl_ssf = ssf; op->o_ssf = ( op->o_sasl_ssf > op->o_tls_ssf ) ? op->o_sasl_ssf : op->o_tls_ssf;

1 0

Re: (ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by ando＠sys-net.it 06 Mar '08

06 Mar '08

norbert(a)rittel.de wrote: > When using attribute names containing hyphens the Set code erroneously considers > the parts to either side of the hyphen as separate tokens. > > For example a <by> clause like > > by set.exact="this/apple-keyword & user/apple-keyword" read > > always yields an empty set. This means that on Apple Open Directory servers set > clauses canot be used with any Apple-supplied attribute as they all begin with > "apple-". The code that parses attribute descriptions appears to be definitely broken, since it does allow underscores but no hyphens, and it does not allow digits in attribute descriptions (including OIDs). This should be fixed now in HEAD, and the patch servers/slapd/sets.c 1.41 -> 1.42 seems to apply to current re24 and re23 without much hassle. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by norbert＠rittel.de 06 Mar '08

06 Mar '08

Full_Name: Norbert Rittel Version: 2.3.27 OS: Mac OS X Server 10.5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.91.71.78) When using attribute names containing hyphens the Set code erroneously considers the parts to either side of the hyphen as separate tokens. For example a <by> clause like by set.exact="this/apple-keyword & user/apple-keyword" read always yields an empty set. This means that on Apple Open Directory servers set clauses canot be used with any Apple-supplied attribute as they all begin with "apple-". Pierangelo Masarati was so kind to verify that this bug is still present in the latest release. Hopefully the fix is a simple diff that we can apply to the older version shipping with Mac OS X Server, too. :-)

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 04 Mar '08

04 Mar '08

--opJtzjQTFsWo+cga Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 03, 2008 at 02:50:49PM -0800, Kurt Zeilenga wrote: > On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote: > In your rights statement, you claim this patch is only derived from =20 > OpenLDAP Software. Is this correct? Are there are works from which =20 > your work is derived? That is, did you copy any material from any other= =20 > work (e.g., Samba)? Please document any in the rights statement and,=20 > when complete, update the ITS (by email reply-all) indicating so. No, it is purely OpenLDAP work using GSS-API libraries. > The rights statement needs to be amended to include a statement that the= =20 > modifications are not subject to Stefan's employer. And then Stefan=20 > needs to send a copy of both statements from his email address to=20 > openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements"=20 > confirming they are correct. I've cc'ed Stefan on this note. Thanks. The modifications are not subject to his employer, but thanks for cc-ing him. Sorry Metze, I should have not forgotten about this. > I note my review is limited to IPR issues. There may well be technical= =20 > issues to address separately from this. These will be handled separately= =20 > (normally post IPR review). Sure, I understand. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHzRUvHvdfyv3qiKkRAga8AJ9aPei2BEkB0cAWnePy1oa0m09s/wCbBWs1 3l6JSyUrgaXSTr3GknJH/oQ= =OedS -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--

1 0

Re: (ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 04 Mar '08

04 Mar '08

May be a useful precision : I think that the second protocol detail above shows that the sync provider in server A "ignores" that the server B has closed the TCP connection. Best regards Ali

1 0

Re: (ITS#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 03 Mar '08

03 Mar '08

On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote: > > --zhXaljGHf11kAtnf > Content-Type: text/plain; charset=iso-8859-2 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote: >> I note that the patch appears to be incomplete. No gssapi.c >> included. > > Sorry about that. Wrong working dir when generating the patch. I've > uploaded more complete file at http://samba.org/~mimir/head- > gssapi.diff > I've also added license notice. Let me know if there's anything else > missing. In your rights statement, you claim this patch is only derived from OpenLDAP Software. Is this correct? Are there are works from which your work is derived? That is, did you copy any material from any other work (e.g., Samba)? Please document any in the rights statement and, when complete, update the ITS (by email reply-all) indicating so. The rights statement needs to be amended to include a statement that the modifications are not subject to Stefan's employer. And then Stefan needs to send a copy of both statements from his email address to openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements" confirming they are correct. I've cc'ed Stefan on this note. I note my review is limited to IPR issues. There may well be technical issues to address separately from this. These will be handled separately (normally post IPR review). Regards, Kurt > > > > cheers, > --=20 > Rafal Szczesniak > Samba Team member http://www.samba.org > Likewise Software http://www.likewisesoftware.com > > > --zhXaljGHf11kAtnf > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: Digital signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ > XF5OP4ZaFhwZ5T6rO1FJ4FM= > =Ii59 > -----END PGP SIGNATURE----- > > --zhXaljGHf11kAtnf-- > >

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 03 Mar '08

03 Mar '08

--zhXaljGHf11kAtnf Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote: > I note that the patch appears to be incomplete. No gssapi.c included. Sorry about that. Wrong working dir when generating the patch. I've uploaded more complete file at http://samba.org/~mimir/head-gssapi.diff I've also added license notice. Let me know if there's anything else missing. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ XF5OP4ZaFhwZ5T6rO1FJ4FM= =Ii59 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--

1 0

(ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 03 Mar '08

03 Mar '08

Full_Name: Ali Pouya Version: 2.4.8 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) Hi, I am testing OpenLdap 2.4.8 in mirrormode. I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with a retry interval of 10 seconds : retry="10 +". An injector writes data to A. The data is replicated in B. But this server UNBINDs then reBINDs to A every 10 seconds ! This continues until slapd on A crashes with a SIGIOT. More investigation in the slapd log shows that the crash is caused by the losing of the client syncrepl connection coming from B ! If instead of B I configure an ordinary replica everything is OK. I think there are two distinct problems : 1) Contrarily to an ordinary replica, a mirror ends the persistent search, 2) slapd crashes (very scarcely) after losing the client syncrepl connection to which it was going to send data. Below you find the backtrace after slapd crash. See also more protocol details after the backtrace. If required I can send any detailed information about my configurations. Thanks for your help Best Regards Ali ============================ (gdb) bt #0 0x009b47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00138815 in raise () from /lib/tls/libc.so.6 #2 0x0013a279 in abort () from /lib/tls/libc.so.6 #3 0x00131d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0805ecb2 in connection_state_closing (c=0xa272585c) at connection.c:680 #5 0x0806c444 in send_ldap_ber (conn=0xa272585c, ber=0x9f7f3c00) at result.c:153 #6 0x0806f192 in slap_send_search_entry (op=0x9f7f3f50, rs=0x9f7f3de0) at result.c:1187 #7 0x08134038 in syncprov_qtask (ctx=0x9f7f4210, arg=0x8e21498) at syncprov.c:809 #8 0x081472df in ldap_int_thread_pool_wrapper (xpool=0x8cbf880) at tpool.c:625 #9 0x00a4e3cc in start_thread () from /lib/tls/libpthread.so.0 #10 0x001da1ae in clone () from /lib/tls/libc.so.6 ============================ More protocol details : 1) As an answer to the SearchAndPersist Request, A sends to B an LDAP message [OPERATION 25] (which I do not know). But this message is not sent to an ordinary replica. 2) I also noticed that after sending UNBIND, B sends a [FIN, ACK] TCP packet. As A does not ack this packet B sends a [RST, ACK] packet 30 micro-seconds later.

1 0

ITS#5145 [Fwd: Corrections for the autogroup README]
by postmaster＠altkom.pl 03 Mar '08

03 Mar '08

-------- Original Message -------- Subject: Corrections for the autogroup README Date: Mon, 03 Mar 2008 11:48:16 +0100 From: Aleksander Adamowski <aleksander.adamowski(a)altkom.pl> Reply-To: postmaster(a)altkom.pl To: hyc(a)symas.com Hi! I'd like to add some grammatical corrections to the README file for the autogroup contrib module: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/a… The description section should read: DESCRIPTION The autogroup overlay allows automated updates of group memberships which meet the requirements of any filter contained in the group definition. The filters are built from the LDAP URI-valued attributes. Any time an object is added/deleted/updated, it is tested for compliance with the filters, and its membership in autogroups is accordingly updated. For searches and compares it behaves like a static group. -- Aleksander Adamowski Administrator systemów korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. +48 601-318-080 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message. -- -- Howard Chu Chief Architect, 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#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by ando＠sys-net.it 01 Mar '08

01 Mar '08

kurt(a)OpenLDAP.org wrote: > IIRC, it's not listed because it only to be used in certain > (extensible) matching rules cases and slapd(8) doesn't support any of > those cases. Technically, I note it's skipped by syn_schema_info() because it has no validator (like many other known syntaxes). I don't recall the reason of this behavior, though. Perhaps it could be relaxed. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by ando＠sys-net.it 01 Mar '08

01 Mar '08

michael(a)stroeder.com wrote: > Take note of this: > > authz-regexp > "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" > "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" > [..] > access to > dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" > by * auth > > > See test of recent RE23 (port 2003) vs. recent RE24 (port 2004): As indicated in OpenLDAP 2.4's man page, now the LDA search operation requires "search" privileges on the "entry" pseudo-attribute of the searchBase. This was introduced to be able to honor the "disclose" privilege (or, at least, in conjunction with code that is used to honore the "disclose" privilege). The man page is erroneous in stating that this requirement and that feature were introduced in OpenLDAP 2.3: the code is indeed present in OpenLDAP 2.3, but actually #ifdef'd; it only became the default behavior in OpenLDAP 2.4. This requirement, as usual, is downgraded to "auth" when performing authc/authz related lookups. I'd take this ITS as a request to fix the documentation (indicate the change since 2.4 and not since 2.3) and to better notify the different behavior since 2.3. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by michael＠stroeder.com 01 Mar '08

01 Mar '08

This is a multi-part message in MIME format. --------------080909030908010602050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Follow-up on openldap-software repeated here... Gavin Henry wrote: > Michael Ströder wrote: >> >> I tried to migrate an existing server from 2.3.39 to 2.4.7 (or also >> CVS RE24). I'm making use of authz-regexp to map user entries when >> they do a SASL Bind with DIGEST-MD5. Also some ACLs are in effect. >> This together used to work on 2.3.x with the existing ACLs. >> >> With 2.4.7 this worked no longer. The user wasn't found. In the ACL >> debug log I've noticed that access to the search root database entry >> (suffix) is requested. When I explicitly grant auth access to this >> entry it works. But why is that needed? Was this an intended change? > > Can you paste them? I've prepared a simplified slapd.conf and a LDIF file (both attached) for this particular migration issue. Take note of this: authz-regexp "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" [..] access to dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" by * auth See test of recent RE23 (port 2003) vs. recent RE24 (port 2004): ----------------------------- snip ----------------------------- $ /opt/openldap-RE24/bin/ldapwhoami -H "ldap://localhost:2003" -Y DIGEST-MD5 -w testsecret SASL/DIGEST-MD5 authentication started SASL username: michael SASL SSF: 128 SASL data security layer installed. dn:uid=michael,ou=users,ou=authz-test,dc=stroeder,dc=local $ /opt/openldap-RE24/bin/ldapwhoami -H "ldap://localhost:2004" -Y DIGEST-MD5 -w testsecret SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) m ----------------------------- snip ----------------------------- If I grant auth access to the database root entry ou=authz-test,dc=stroeder,dc=local it works (see comment of this particular ACL in attached slapd.conf). With RE23 it also works without this ACL! Ciao, Michael. --------------080909030908010602050105 Content-Type: text/x-ldif; name="initialload.ldif" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="initialload.ldif" dn: ou=authz-test,dc=stroeder,dc=local objectClass: organizationalUnit ou: authz-test dn: ou=Users,ou=authz-test,dc=stroeder,dc=local objectClass: organizationalUnit ou: Users dn: uid=michael,ou=Users,ou=authz-test,dc=stroeder,dc=local uid: michael objectClass: account objectClass: simpleSecurityObject userpassword: testsecret --------------080909030908010602050105 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" include /opt/openldap-RE24/etc/openldap/schema/core.schema include /opt/openldap-RE24/etc/openldap/schema/cosine.schema # Define global ACLs to disable default read access. pidfile /home/michael/temp/openldap-authzto-testbed/RE24/run/slapd-1.pid argsfile /home/michael/temp/openldap-authzto-testbed/RE24/run/slapd-1.args modulepath /opt/openldap-RE24/libexec/openldap moduleload back_hdb.la authz-regexp "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth" "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)" database hdb suffix "ou=authz-test,dc=stroeder,dc=local" directory /home/michael/temp/openldap-authzto-testbed/RE24/data # Index-Konfiguration index objectClass,uid eq sizelimit -1 # User entries # ------------------------ access to dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local" by * auth # Why the hell is this ACL needed for SASL Bind with authz-regexp with OpenLDAP 2.4? access to dn.base="ou=authz-test,dc=stroeder,dc=local" by * auth --------------080909030908010602050105--

1 0

(ITS#5400) authz-regexp migration issue: ACLs of 2.3 no longer work with 2.4.8
by michael＠stroeder.com 01 Mar '08

01 Mar '08

Full_Name: Michael Ströder Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.75.104) A configuration using authz-regexp fully functional with appropriate ACLs was working in RE23 but does not work in 2.4.8 anymore. http://www.openldap.org/lists/openldap-software/200802/msg00373.html More to follow...

1 0

Re: (ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by kurt＠OpenLDAP.org 29 Feb '08

29 Feb '08

On Feb 29, 2008, at 1:56 AM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.114.177) > > > Although implemnted since 2.0 the LDAP Syntax with > 1.3.6.1.4.1.1466.115.121.1.58 > (Substring Assertion) is not listed in subschema subentry. IIRC, it's not listed because it only to be used in certain (extensible) matching rules cases and slapd(8) doesn't support any of those cases. I noticed that this came up because someone was trying to use this syntax an attribute description. That attribute description is likely bogus.

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by ando＠sys-net.it 29 Feb '08

29 Feb '08

jclarke(a)linagora.com wrote: > jclarke(a)linagora.com a écrit : >>>> When slapcat is writing it's output to disk, it ignores any errors >>>> (with slapcat -l output_file or slapcat > output_file). If an error is >>>> encountered, such as "No space left on device", slapcat then exits >>>> normally with a return code of 0. > > Thanks for commiting this to HEAD. > > Is there any chance of seeing it a future maintenance release of 2.3? As soon as one is planned, if ever. I can't say anything right now, since this issue is not a showstopper, and 2.3.41 has just been released. Unless 2.4 becomes stable any soon, there'll probably be another 2.3 at some point. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by jclarke＠linagora.com 29 Feb '08

29 Feb '08

jclarke(a)linagora.com a écrit : >>> When slapcat is writing it's output to disk, it ignores any errors >>> (with slapcat -l output_file or slapcat > output_file). If an error is >>> encountered, such as "No space left on device", slapcat then exits >>> normally with a return code of 0. Thanks for commiting this to HEAD. Is there any chance of seeing it a future maintenance release of 2.3? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

ITS#5396
by ecizaguirre＠gmv.com 29 Feb '08

29 Feb '08

Another update about this problem. Connections between slpad and the remote active directory servers remains in ESTABLISHED state for a long time and changes to CLOSE_WAIT state in the slapd server. In the active directory servers the connections then changes to FIN_WAIT_2, so it seems the slapd server is not sending the FIN packet to close the socket. Cheers. Eduardo ________________________________ De: Eduardo Izaguirre Pazos Enviado el: jueves, 28 de febrero de 2008 13:21 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 An update about the case, the problem seems to be related with the connections which remains in CLOSE_WAIT state, as an example: [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

(ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry
by michael＠stroeder.com 29 Feb '08

29 Feb '08

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.114.177) Although implemnted since 2.0 the LDAP Syntax with 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) is not listed in subschema subentry.

1 0

(ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times
by ssnet＠ua.es 28 Feb '08

28 Feb '08

Full_Name: maria saez Version: 2.4.8 OS: debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.145.230.2) An account locked in a consumer needs two password changes in the provider to be unlocked. The first time that we change the password in the provider the password change is replicated in the consumer but the account remains locked. Can you help us? We have openldap-2.4.7 and openldap-2.4.8 Is this situation normal? We have the following configuration: Provider ------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq # define the replica provider for this database # (last directives in database section) overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Consumer ---------------------------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" ppolicy_use_lockout syncrepl rid=123 provider=ldaps://xx.xx.es:xx/ binddn="cn=config" bindmethod=simple credentials=xx searchbase="dc=xx,dc=es" schemachecking=on type=refreshAndPersist retry="60 +" overlay syncprov ------------------------------------------------------------------- The policy we have defined: dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es cn: Standard Policy objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: 2.5.4.35 pwdLockout: TRUE pwdLockoutDuration: 0 pwdInHistory: 6 pwdCheckQuality: 2 pwdExpireWarning: 10 pwdMaxAge: 120 pwdMinLength: 5 pwdGraceAuthnLimit: 3 pwdAllowUserChange: TRUE pwdMustChange: TRUE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: TRUE pwdMinAge: 120 -------------------------------------------------------------

1 0

RE: (ITS#5397) syncrepl badly processes modify rdn operation
by emmanuel.duru＠atosorigin.com 28 Feb '08

28 Feb '08

OK I have tested it, it works fine. Thank you. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 28 février 2008 16:24 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5397) syncrepl badly processes modify rdn operation > > emmanuel.duru(a)atosorigin.com wrote: > > > When the provider server receives a modify RDN operation, syncrepl > replicates it > > with the full new DN as new RDN. > > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets > the newrdn > > from a call to dnRdn() function, which only modifies the bv_len of the > ber > > struct, but not the value itself. Following this, the > backend:be_modrdn() > > function does not check the length, and gets the full DN as RDN value > (at least > > back_ldap does this). > > Fixed in HEAD (the patch should apply more or less to 2.3 as well). I > note that slapo-auditlog might siffer from the same problem; other > overlays could print the incorrect newRDN in log messages. > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- >

1 0

Re: (ITS#5397) syncrepl badly processes modify rdn operation
by ando＠sys-net.it 28 Feb '08

28 Feb '08

emmanuel.duru(a)atosorigin.com wrote: > When the provider server receives a modify RDN operation, syncrepl replicates it > with the full new DN as new RDN. > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn > from a call to dnRdn() function, which only modifies the bv_len of the ber > struct, but not the value itself. Following this, the backend:be_modrdn() > function does not check the length, and gets the full DN as RDN value (at least > back_ldap does this). Fixed in HEAD (the patch should apply more or less to 2.3 as well). I note that slapo-auditlog might siffer from the same problem; other overlays could print the incorrect newRDN in log messages. 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 Email: pierangelo.masarati(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