openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 02 Dec '10

02 Dec '10

This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by MDT Evans <m.d.t.evans(a)qmul.ac.uk>. I have not assigned rights and/or interest in this work to any party. I, MDT Evans, 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. -- Dr Martin DT Evans, Computing Services/Central Servers.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 02 Dec '10

02 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: > I have put a preliminary version of patches that modify the unique > overlay here > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz > > They add a new configuration attribute olcUniqueAllowManageBypass (it is > prohibitively long for a name, though) that, if set to TRUE, triggers > the uniqueness checks not to be performed if the operation has manage > privilegies on the entry. There are three separate patches, > configuration code regarding the new attribute, the checks in > unique_{add,modify,modrdn} and manpage modifications. > After a conversation with Howard, I have modified the patches so that the overlay check for the ManageDsaIt control instead. That control should be set for each operation coming from replication. The patches are here: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz Is there anything else that comes to mind? Again the IPR notice: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz3cLcACgkQ9GWxeeH+cXuKBACfSvRQJvNWpVm16pWhJ3wfAxH2 JBwAn3CDasTgcMONMSFyIaqH0CZpv1MN =YaoF -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.203.245) Submitted by: hallvard apply_modify_to_entry() and ldif_back_add() can return with rs->sr_text pointing into the stack, at textbuf[]. Fixing.

1 0

RE : RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 01 Dec '10

01 Dec '10

Thank's a lot, It's work fine with the new rwm.c Regards, Olivier=

1 0

Re: (ITS#6364) refint needs to have rootdn set
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

Quanah Gibson-Mount wrote: > The refint overlay doesn't necessarily work correctly without a rootd= n > being set on the database it is applying to. This requirement should= > be documented in the man page. Fixed in the manpage, but not in the admin guide. Michael=5FStr=F6der wrote: > I'd argue that slapd should not even start if such a strong > requirement of an overlay is not met by configuration. Leaving that for Howard, but I don't think we can do that now. cn=3Dconfig should then also refuse to delete rootdn, otherwise we'd ha= ve the worse behavior that slapd won't start after a cn=3Dconfig update. Peter Mogensen wrote: > I've veryfied that my refint overlay is not working. > However I have a rootdn defined for the database, but it is set to=20= > cn=3Dconfig. > Could it be that the rootdn has to be in the scope of the database fo= r=20 > refint to work=3F I don't think so. Hopefully it was ITS#6663 or ITS#6730, now fixed. --=20 Hallvard

1 0

Re: (ITS#6663) refint not altering last attribute on delete
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

knewell(a)math.arizona.edu writes: > refint does not alter the value of an attribute to refint_nothing when > the last "member" of a group is deleted. Fixed in CVS HEAD. -- Hallvard

1 0

(ITS#6730) refint with subtrees/subordinates broken
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Subtree rename breaks if an attribute contains both the base DN and a subordinate DN: It only handles the base DN if it is in the first attribute value, and (attempts to) produce the wrong new base. Subtree delete is coded but ignored: Refint searches for deleted subordinate DNs, but the test for deleting them is inverted. Also a modification can update modifiersName several times per entry. Fixing.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com 30 Nov '10

30 Nov '10

I'm not sure if this is still relevant or useful, but included below is a set of steps that will reliably reproduce the issue and a backtrace using autogroup from HEAD and ppolicy, which as noted causes segmentation faults in the slaptools utilities (e.g., slapcat). Note that this backtrace is from a build of 2.4.21, but the issue is present and occurs with 2.4.23 as well, as Norbert has stated. rgs@ldapmaster3:~# ldapmodify -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: ppolicy.la modifying entry "cn=module{0},cn=config" rgs@ldapmaster3:~# ldapadd -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret dn: olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {3}ppolicy olcPPolicyHashCleartext: FALSE olcPPolicyForwardUpdates: FALSE olcPPolicyUseLockout: TRUE adding new entry "olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config" rgs@ldapmaster3:~# cat /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}smbk5pwd.la olcModuleLoad: {4}ppolicy.la structuralObjectClass: olcModuleList creatorsName: cn=config entryUUID: f83e3413-5ba7-4c85-9bf7-ed8728d9fbce createTimestamp: 20091018205311Z entryCSN: 20101129205850.805900Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20101129205850Z rgs@ldapmaster3:~/ldap/ldifs/ppolicy# gdb --args slapcat -n1 (gdb) run Starting program: /usr/sbin/slapcat -n1 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271 1271 /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c: No such file or directory. in /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c (gdb) backtrace #0 0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271 #1 0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd700, rs=0x7fffffffd660, which=<value optimized out>, oi=0x7ffff83220c0, on=0x7ffff8341e50) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659 #2 0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd700, rs=0xfffffffffffffff0, which=4294957760) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721 #3 0x00007ffff2846141 in autogroup_db_open (be=<value optimized out>, cr=<value optimized out>) at autogroup.c:1754 #4 0x00007ffff7f6e994 in over_db_open (be=<value optimized out>, cr=0x7fffffffdfb0) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155 #5 0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8315f80, cr=0x7fffffffdfb0) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224 #6 0x00007ffff7f13a83 in backend_startup (be=0x7ffff8315f80) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:278 #7 0x00007ffff7f742cc in slap_tool_init (progname=<value optimized out>, tool=2, argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780 #8 0x00007ffff7f7335a in slapcat (argc=-9536, argv=<value optimized out>) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51 #9 0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657 (gdb) x 0x7fffffffd700 0x7fffffffd700: 0xffffd870 (gdb) x 0x7fffffffd660 0x7fffffffd660: 0x00000000 For reference, line 1271, located within the ppolicy_restrict function, looks like so: if ( op->o_conn && !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) { -Ryan

1 0

(ITS#6729) slapd segfault caused by ldapsearch -Y OTP
by daniel＠pluta.biz 30 Nov '10

30 Nov '10

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:223:aeff:feac:1f51) For details and a patch please visit: http://www.openldap.org/its/index.cgi/Development?id=6475;selectid=6475#fol…

1 0

(ITS#6728) libldap TCP/SASL problems
by quanah＠zimbra.com 29 Nov '10

29 Nov '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) As reported at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604122 Hello, During some tests for nslcd[1], I found that if the SASL_SECPROPS in /etc/ldap/ldap.conf is incompatible with the SASL_MECH, then the library: - open a useless TCP connection to the server - check the mechanism and fail - close the TCP connection ===== /etc/ldap/ldap.conf BASE dc=baby-gnu,dc=org URI ldap://192.168.122.4 SASL_MECH DIGEST-MD5 SASL_SECPROPS noactive ===== /etc/ldap/ldap.conf ===== Wireshark capture No. Time Source Destination Protocol Info 3 2.728967 192.168.122.3 192.168.122.4 TCP 51521 > ldap [SYN] Seq=0 [...] 4 2.729699 192.168.122.4 192.168.122.3 TCP ldap > 51521 [SYN, ACK] Seq=0 [...] 5 2.729714 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=1 [...] 6 2.739576 192.168.122.3 192.168.122.4 TCP 51521 > ldap [FIN, ACK] Seq=1 [...] 7 2.740686 192.168.122.4 192.168.122.3 TCP ldap > 51521 [FIN, ACK] Seq=1 [...] 8 2.740702 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=2 [...] ===== Wireshark capture ===== ldapsearch ldapsearch -U dad -s base -LLL supportedSASLMechanisms ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found ===== ldapsearch As the problem is found in a software using the libldap, I conclude the problem is in the lib and not in ldapsearc. Regards.

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