openldap-bugs March 2015

openldap-bugs@openldap.org

25 participants
65 discussions

(ITS#8084) Segfault on ppc64 caused by commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24
by jsynacek＠redhat.com 19 Mar '15

19 Mar '15

Full_Name: Jan Synacek Version: master OS: GNU/Linux URL: Submission from: (NULL) (213.175.37.10) On PPC64, slapd segfaults on startup when using mdb as the backend. Reproducer: 1) ./configure && make && make install STRIP="" 2) slapd -d1 -h "ldap:/// ldapi:///" -f slapd.conf $ cat slapd.conf include /etc/opldldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args database mdb directory /var/lib/ldap/ suffix dc=foo,dc=bar,dc=com rootdn "cn=Manager,dc=foo,dc=bar,dc=com" # password is 'x' rootpw {SSHA}tOSmeQCcYIm1S9ujgpg2Km5rpUnR9dRBD%D There seems to be a program memory corruption, since the backtrace doesn't make any sense and valgrind reports "Illegal instruction". gdb --args -d1 -h "ldap:/// ldapi:///" -f slapd.conf ... (gdb) r ... Program received signal SIGSEGV, Segmentation fault. 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () (gdb) bt #0 0x000000001014b98c in 000006ae.plt_call.pthread_mutex_unlock@@GLIBC_2.3+0 () #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 #2 0x00000000100b91d4 in mdb_db_open (be=0x102b02c0, cr=0xfffffffe9a0) at init.c:174 #3 0x000000001003c130 in backend_startup_one (be=0x102b02c0, cr=0xfffffffe9a0) at backend.c:224 #4 0x000000001003c58c in backend_startup (be=0x102b02c0) at backend.c:330 #5 0x000000001005d650 in slap_startup (be=0x0) at init.c:220 #6 0x0000000010009b88 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:997 (gdb) up #1 0x000000001014d79c in mdb_env_open (env=0x1034a4e0, path=0x102d5250 "/var/lib/ldap/", flags=536870912, mode=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:4540 4540 env->me_path = strdup(path); I bisected the problem and the following commit is the problem: commit 6ad38fef3fe63ff86c1e6cff3c6330353b21cc24 Author: Howard Chu <hyc(a)openldap.org> Date: Wed Jan 14 19:05:17 2015 +0000 Fix typo in 45146ba21a9ee494e7058ca7a173fcc6b27df744 diff --git a/servers/slapd/schema_init.c b/servers/slapd/schema_init.c index 46d1c6d..08e733f 100644 --- a/servers/slapd/schema_init.c +++ b/servers/slapd/schema_init.c @@ -1826,7 +1826,7 @@ UTF8StringValidate( if( LDAP_UTF8_OFFSET( (char *)u ) != len ) return LDAP_INVALID_SYNTAX; } - if( u >= len ) { + if( u > end ) { return LDAP_INVALID_SYNTAX; } This problem is already present in 2.4.40, but absent in 2.4.39.

1 0

Re: (ITS#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--001a113602ac48c9b00511a317b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 101%. Leonid 18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Howard Chu" <hyc(a)symas.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: > leo(a)yuriev.ru wrote: > >> As far as I remember this was fixed in ReOpenLDAP at January. >> Valgrind was reporting 'using uninitialized'. >> > > Not happening here. mdb_cursor_first() always initializes mc_ki. > >> >> Leonid. >> >> @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, >> MDB_dbi dbi, MDB_xcursor *mx) >> mc->mc_top =3D 0; >> mc->mc_pg[0] =3D 0; >> mc->mc_flags =3D 0; >> + mc->mc_ki[0] =3D 0; >> if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { >> mdb_tassert(txn, mx !=3D NULL); >> mc->mc_xcursor =3D mx; >> >> >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113602ac48c9b00511a317b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, in some case valgrind was reported as I noticed, sure 10= 1%. Leonid <div class=3D"gmail_quote">18.03.2015 23:12 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Howard Chu" <<a hr= ef=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: <blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As far as I remember this was fixed in ReOpenLDAP at January. Valgrind was reporting 'using uninitialized'. </blockquote> Not happening here. mdb_cursor_first() always initializes mc_ki. <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Leonid. @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, MDB_dbi dbi, MDB_xcursor *mx) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_top =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_pg[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_flags =3D 0; +=C2=A0 =C2=A0 =C2=A0 =C2=A0mc->mc_ki[0] =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (txn->mt_dbs[dbi].md_flags & M= DB_DUPSORT) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mdb_tassert(= txn, mx !=3D NULL); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mc->mc_xc= ursor =3D mx; </blockquote> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --001a113602ac48c9b00511a317b0--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 19 Mar '15

19 Mar '15

--047d7b87466456cd650511a30230 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can see the bugs and fix it in openldap. Leonid 18.03.2015 22:17 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C "Howard Chu" <hyc(a)symas.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0=D0=BB: > leo(a)yuriev.ru wrote: > >> Fixed in ReOpenLDAP week ago. >> https://github.com/ReOpen/ReOpenLDAP/commit/ >> 6de52172bc0f8309dd00c329452213d51e5573a9 >> > > Leo: if you intend for this patch to be adopted here, please attach the > IPR notice as documented > > http://www.openldap.org/devel/contributing.html > > Note that, as written, your patch is unacceptable as it violates the "one > functional change per patch" condition. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7b87466456cd650511a30230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howard, I don't submit this path or so on. But you can s= ee the bugs and fix it in openldap. Leonid <div class=3D"gmail_quote">18.03.2015 22:17 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7= =D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Howard Chu" <<a hr= ef=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>> =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: <blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:leo@yuriev.ru" target=3D"_blank">leo(a)yuriev.ru</a> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Fixed in ReOpenLDAP week ago. <a href=3D"https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00= c329452213d51e5573a9" target=3D"_blank">https://github.com/ReOpen/Re= OpenLDAP/commit/6de52172bc0f8309dd00c329452213d51e5573a9</a><= br> </blockquote> Leo: if you intend for this patch to be adopted here, please attach the IPR= notice as documented <a href=3D"http://www.openldap.org/devel/contributing.html" target=3D"_blan= k">http://www.openldap.org/devel/contributing.html</a> Note that, as written, your patch is unacceptable as it violates the "= one functional change per patch" condition. -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> --047d7b87466456cd650511a30230--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by ryan＠nardis.ca 18 Mar '15

18 Mar '15

On Wed, Mar 18, 2015 at 05:06:33AM +0000, ryan(a)nardis.ca wrote: >I get the following crash on master and RE24. not every time, but most times. > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 0x7fffe6ffe700 (LWP 25923)] >0x0000000000511d45 in syncprov_op_mod (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at >syncprov.c:2129 >2129 if ( m2->mi_op->o_threadctx == op->o_threadctx ) { Same testcase, different crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffecde1700 (LWP 1747)] 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 1418 mt->mt_mods = mt->mt_mods->mi_next; (gdb) bt #0 0x000000000051ae5e in syncprov_op_cleanup (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at syncprov.c:1418 #1 0x00000000004417f3 in slap_cleanup_play (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:567 #2 0x0000000000441fac in send_ldap_response (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:759 #3 0x0000000000442793 in slap_send_ldap_result (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at result.c:886 #4 0x00000000004e472a in mdb_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:672 #5 0x00000000004baadd in overlay_op_walk (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify, oi=0x8aae60, on=0x0) at backover.c:696 #6 0x00000000004bad01 in over_op_func (op=0x7fffe0000aa0, rs=0x7fffecde0ac0, which=op_modify) at backover.c:749 #7 0x00000000004bae35 in over_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at backover.c:788 #8 0x000000000044bacb in fe_op_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:303 #9 0x000000000044b37e in do_modify (op=0x7fffe0000aa0, rs=0x7fffecde0ac0) at modify.c:177 #10 0x000000000042bdf3 in connection_operation (ctx=0x7fffecde0bf0, arg_v=0x7fffe0000aa0) at connection.c:1134 #11 0x000000000042c3a3 in connection_read_thread (ctx=0x7fffecde0bf0, argv=0xb) at connection.c:1280 #12 0x000000000053772e in ldap_int_thread_pool_wrapper (xpool=0x883b40) at tpool.c:958 #13 0x00007ffff77ad0a4 in start_thread (arg=0x7fffecde1700) at pthread_create.c:309 #14 0x00007ffff74e204d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Looks like at this point mt either points to garbage, or is itself garbage. Reverting 8eb9aa7d resolves both crashes.

1 0

Re: (ITS#8080) nssov allows users to change anyone's password
by hyc＠symas.com 18 Mar '15

18 Mar '15

Ryan Tandy wrote: > On Mon, Mar 16, 2015 at 05:44:50PM +0000, hyc(a)symas.com wrote: >>> ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-require-old-password-… >>> >> >> I think this patch is a bit off; it prevents root from supplying the >> old pwd. (Which it must do if changing its own.) > > I don't follow, sorry. If root is the pwdmgr, then the current code > already omits the old password, even if the request includes it, and > passwd_extop() seems to be fine with that. True. > And if root auths as a DN > different from the pwdmgr DN, then it's a normal self-change and the old > password is checked. Did I get some part of that wrong? > > You could argue that we should always check the old password if > provided, even when working as pwdmgr. I would agree with that. It's not > what the current code does, though. Right, I think if we're in here anyway we should fix that. > And on my systems at least, passwd running as root never asks for the > current password, even when changing root's own password. (Of course > that might be different elsewhere.) Admittedly, it's been a long time since I've changed a root password, since I just use ssh keys most of the time. -- -- 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#8062) Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
by hyc＠symas.com 18 Mar '15

18 Mar '15

leo(a)yuriev.ru wrote: > As far as I remember this was fixed in ReOpenLDAP at January. > Valgrind was reporting 'using uninitialized'. Not happening here. mdb_cursor_first() always initializes mc_ki. > > Leonid. > > @@ -7301,6 +7551,7 @@ mdb_cursor_init(MDB_cursor *mc, MDB_txn *txn, > MDB_dbi dbi, MDB_xcursor *mx) > mc->mc_top = 0; > mc->mc_pg[0] = 0; > mc->mc_flags = 0; > + mc->mc_ki[0] = 0; > if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { > mdb_tassert(txn, mx != NULL); > mc->mc_xcursor = mx; > > > > > -- -- 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#8081) syncprov crash in syncprov_op_mod
by hyc＠symas.com 18 Mar '15

18 Mar '15

leo(a)yuriev.ru wrote: > Fixed in ReOpenLDAP week ago. > https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00c329452213d… Leo: if you intend for this patch to be adopted here, please attach the IPR notice as documented http://www.openldap.org/devel/contributing.html Note that, as written, your patch is unacceptable as it violates the "one functional change per patch" condition. -- -- 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#8082) slapd leaks memory - using clang to do static analysis
by hyc＠symas.com 18 Mar '15

18 Mar '15

ludovic(a)hirlimann.net wrote: > Full_Name: Ludovic Hirlimann > Version: trunk > OS: Fedora 21 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:e34:ed45:8a70:eab1:fcff:fede:413) Thanks for the report but this "leak" is entirely benign, the code is only executed once at startup and leaks don't accumulate during runtime. We'll fix it but it's far from high priority. > > [ludo@Oulanl openldap]$ ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer > ./servers/slapd/slapcat > 550969a1 could not stat config file "/usr/local/etc/openldap/slapd.conf": No > such file or directory (2) > slapcat: bad configuration file! > > ================================================================= > ==11688==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 4104 byte(s) in 1 object(s) allocated from: > #0 0x4b2b50 in calloc (/home/ludo/openldap/servers/slapd/slapd+0x4b2b50) > #1 0x7b33cd in ber_memcalloc_x > /home/ludo/openldap/libraries/liblber/memory.c:283:9 > #2 0x5703c3 in ch_calloc > /home/ludo/openldap/servers/slapd/ch_malloc.c:104:23 > #3 0x5005e7 in init_config_argv > /home/ludo/openldap/servers/slapd/config.cA1A118:12 > #4 0x505491 in read_config_file > /home/ludo/openldap/servers/slapd/config.c:727:2 > #5 0x4d4771 in read_config > /home/ludo/openldap/servers/slapd/bconfig.c:4485:7 > #6 0x651804 in slap_tool_init > /home/ludo/openldap/servers/slapd/slapcomm.c.c:672:7 > #7 0x64fb63 in slapcat /home/ludo/openldap/servers/slapd/slapcat.c:53:2 > #8 0x4d1b76 in main /home/ludo/openldap/servers/slapd/main.c:411:10 > #9 0x7fa949271fdf in __libc_start_main (/lib64/libc.so.6+0x1ffdf) > > SUMMARY: AddressSanitizer: 4104 byte(s) leaked in 1 allocation(s). > > > -- -- 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#8083) userPassword rewrite for bind operation
by michael＠stroeder.com 18 Mar '15

18 Mar '15

This is a cryptographically signed message in MIME format. --------------ms010508020906020207020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable nespor(a)id.ethz.ch wrote: > In certain situations users may welcome the possibility > to authenticate in different applications using the same > user uid, but an alternative user password value. There were already some people trying something like this but IMO it's a = very=20 broken concept anyway. If you need credential separation because of different security policies = then=20 be honest and create separate user accounts for real role separation. Ciao, Michael. --------------ms010508020906020207020304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODE1NDAzNlowLwYJKoZIhvcNAQkEMSIE IH/x9ipHP/0EoDn7l6JMVIhkpWH+Bu1JFcvFkMJ9XOzjMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQAiZehM90aZW6b4wJkNiYlX25pZ+859fbJXZByII85FBJIYp8Z1xx3D BW0YwXYi3mkcHWucFeYmgh7vc4WXkez/2dQ8LIbFJjx5w2ujfdUkiXCSIndgRP0QHRkfEEsK qmgN1C6hKAxRdySR9SECzFdWv4VQWixUF824UcOmFbBxr32n2dA0C8MdFT069T+1OEak/9sn SmNl6stRDVW+GW6uiZu5BBPHGDSjemI8iHKs4WwKEPO2z19Sb9VEUDYjLDR8ysMxiapXS7AW oSLVy0CWHP/PvQEtPVx25oyHPrZTyvyNemy1Ux48SwH09crHaOWQlbQAEP2pZRZmew02+hYx AAAAAAAA --------------ms010508020906020207020304--

1 0

(ITS#8083) userPassword rewrite for bind operation
by nespor＠id.ethz.ch 18 Mar '15

18 Mar '15

Full_Name: Vlado Nespor Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/vlado-nespor-150318.patch Submission from: (NULL) (129.132.179.222) In certain situations users may welcome the possibility to authenticate in different applications using the same user uid, but an alternative user password value. In order to avoid the creation of a new user entry, and repeating the same values for all user attributes, but the attribute userPassword, virtual views (see slapd-relay(5) and slapo-rwm(5)) seem to be a good alternative. Although the mapping of the userPassword attribute in the relay backend configuration works fine for e.g the search operation, it does not work for the bind operation. For example, for the following configuration in slapd.conf ----------------------- database relay suffix "ou=webUsers,ou=auth,o=example" relay "ou=users,ou=auth,o=example" overlay rwm rwm-suffixmassage "ou=webUsers,ou=auth,o=example" "ou=users,ou=auth,o=example" rwm-map attribute sn * rwm-map attribute cn * rwm-map attribute uid * rwm-map attribute userPassword webUserPassword rwm-map attribute * -----------------------%%0 the search operation in "ou=webUsers,ou=auth,o=example" would present the password value stored in the attribute webUserPassword (from "ou=users,ou=auth,o=example"). But for the bind operation the user has to use the password value stored in the attribute userPassword (and not in the attribute webUserPassword, as one could expect). The patch, presented in ftp://ftp.openldap.org/incoming/vlado-nespor-150318.patch aims to extend the functionality of virtual views. With the patch applied, the mapping of the attribute userPassword in the above example should also work for the user bind operation. (In order to use the alternative password value stored in webUserPassword, the application (LDAP client) just needs to modify the search base.) The changes in the patch have been tested for simple authentication, and they should work for the following backends: back-bdb back-hdb back-mdb back-sql There are a few examples (configurations and data) in ftp://ftp.openldap.org/incoming/vlado-nespor-150318-examples.tar to illustrate the idea and to allow simple tests. The patch has been tested in our production (back-hdb) for several moths, and there were no problems detected.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2015