openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

17 Mar '15

Full_Name: Ryan Tandy Version: master (05ea787), RE24 (082e192) OS: Debian unstable URL: ftp://ftp.openldap.org/incoming/20150317_rtandy_syncprovsegv.tgz Submission from: (NULL) (24.68.37.4) hi, ./configure CFLAGS="-g -O0" --disable-bdb --disable-hdb --enable-syncprov reproducer: ftp://ftp.openldap.org/incoming/20150317_rtandy_syncprovsegv.tgz note this is _not_ delta-syncrepl. ./prepare ./runslapd (backgrounds a consumer, runs e e producer in gdb in the foreground) in another terminal, once the consumer has connected (5 seconds retry): ./modify 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 ) { (gdb) bt #0 0x0000000000511d45 in syncprov_op_mod (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at syncprov.c:2129 #1 0x00000000004b6e91 in overlay_op_walk (op=0x7fffd41024a0, rs=0x7fffe6ffdae0, which=op_modify, oi=0x895a30, on=0x895c10) at backover.c:661 #2 0x00000000004b715f in over_op_func (op=0x7fffd41024a0, rs=0x7fffe6ffdae0, which=op_modify) at backover.c:730 #3 0x00000000004b7293 in over_op_modify (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at backover.c:769 #4 0x00000000004494c1 in fe_op_modify (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at modify.c:303 #5 0x0000000000448d94 in do_modify (op=0x7fffd41024a0, rs=0x7fffe6ffdae0) at modify.c:177 #6 0x0000000000429a9f in connection_operation (ctx=0x7fffe6ffdc10, arg_v=0x7fffd41024a0) at connection.c:1155 #7 0x000000000042a039 in connection_read_thread (ctx=0x7fffe6ffdc10, argv=0xb) at connection.c:1291 #8 0x000000000052b511 in ldap_int_thread_pool_wrapper (xpool=0x870270) at tpool.c:696 #9 0x00007ffff77ad0a4 in start_thread (arg=0x7fffe6ffe700) at pthread_create.c:309 #10 0x00007ffff74e204d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) p m2->mi_op $2 = (Operation *) 0xc8 ^ that looks a bit bogus. haven't started to investigate or bisect just yet. will look more tomorrow. apologies in advance if I've duplicated an existing ITS by accident :)

1 0

Re: (ITS#8080) nssov allows users to change anyone's password
by ryan＠nardis.ca 16 Mar '15

16 Mar '15

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. 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. 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.)

1 0

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

16 Mar '15

Thanks for the report. > I also noticed that pwmod always bails out if no pwdmgr dn is configured, even > if it shouldn't be needed (ie. user changing own password). > > The following patches solve these problems by requiring the old password to be > supplied unless working as pwdmgr; by only allowing root to authc or pwmod as > pwdmgr (adapted from nss-pam-ldapd); and by silently skipping the pwdmgr check > if it's not configured. > > 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.) > ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-only-allow-root-to-be… > ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-allow-user-pwmod-with… -- -- 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#8080) nssov allows users to change anyone's password
by ryan＠nardis.ca 15 Mar '15

15 Mar '15

Full_Name: Ryan Tandy Version: 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) If I write to the socket, un-base64ed: AQAAACVOAAAGAAAAcnRhbmR5HAAAAHVpZD1ydGFuZHksZGM9ZXhhbXBsZSxkYz1jb20GAAAAcGFzc3dkAAAAAAQAAABhc2Rm (pwmod action, uid 'rtandy', dn 'uid=rtandy,dc=example,dc=com', service 'passwd', opw '', npw 'asdf'90D nssov will change rtandy's password, assuming ACLS permit userPassword mods by self. Furthermore, if I set nssov-pwdmgr-dn to 'cn=pwdmgr,dc=example,dc=com' and then write to the socket, un-base64ed: AQAAACVOAAAGAAAAcnRhbmR5GwAAAGNuPXB3ZG1ncixkYz1leGFtcGxlLGRjPWNvbQYAAABwYXNzd2QAAAAABAAAAGFzZGY= (pwmod action, uid 'rtandy', dn 'cn=pwdmgr,dc=example,dc=com', service 'passwd', opw '', npw 'asdf') then rtandy's password will be changed using pwdmgr privileges. IMO only root should be allowed to do this, not unprivileged users. (passwd(1) enforces the same rule.) I also noticed that pwmod always bails out if no pwdmgr dn is configured, even if it shouldn't be needed (ie. user changing own password). The following patches solve these problems by requiring the old password to be supplied unless working as pwdmgr; by only allowing root to authc or pwmod as pwdmgr (adapted from nss-pam-ldapd); and by silently skipping the pwdmgr check if it's not configured. ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-require-old-password-… ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-only-allow-root-to-be… ftp://ftp.openldap.org/incoming/20150315_rtandy_nssov-allow-user-pwmod-with…

1 0

(ITS#8079) nssov usergroup check always fails (patch)
by ryan＠nardis.ca 13 Mar '15

13 Mar '15

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (24.68.37.4) The usergroup check in pam_authz always fails, because the compare result is overwritten before it's returned. Quanah already fixed this for hostservice in b3712e4f, this patch does the same for usergroup. ftp://ftp.openldap.org/incoming/20150313_rtandy_nssov-fix-compare-for-userg…

1 0

Re: (ITS#8077) unknown envflags keyword
by quanah＠zimbra.com 12 Mar '15

12 Mar '15

--On Friday, March 13, 2015 12:10 AM +0100 Dieter Kl=C3=BCnter=20 <dieter(a)dkluenter.de> wrote: > please read slapd-mdb{5} and provide correct examples. The {}'s and ","s are meta characters, noting they are the possible values. = They are not literally meant as a usage example. As noted in = slapd.conf(5): Arguments on configuration lines are separated by white space --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8077) unknown envflags keyword
by dieter＠dkluenter.de 12 Mar '15

12 Mar '15

Am Thu, 12 Mar 2015 12:59:49 -0700 schrieb Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, March 11, 2015 6:29 PM +0000 dieter(a)dkluenter.de > wrote: >=20 > > Because that is a standard slapd.conf in my test environment, but > > the same with and without curly brackets. >=20 > Hi Dieter, >=20 > Your usage is an error. See=20 > <https://www.openldap.org/its/private.cgi/?findid=3D8016> >=20 > Prior to 8016, it was silently ignored. It is now no longer silent. please read slapd-mdb{5} and provide correct examples. -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53=C2=B037'09,95"N 10=C2=B008'02,42"E

1 0

Re: (ITS#8077) unknown envflags keyword
by quanah＠zimbra.com 12 Mar '15

12 Mar '15

--On Wednesday, March 11, 2015 6:29 PM +0000 dieter(a)dkluenter.de wrote: > Because that is a standard slapd.conf in my test environment, but the > same with and without curly brackets. Hi Dieter, Your usage is an error. See <https://www.openldap.org/its/private.cgi/?findid=8016> Prior to 8016, it was silently ignored. It is now no longer silent. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8078) The configured TimeOut in the Back-meta overlay is not used during the connction phase
by elecharny＠apache.org 12 Mar '15

12 Mar '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.46.56.240) the back-meta overlay meta_back_init_one_conn() method set the timeout to get the result to a value which is not the one configured (network-timeout AFAIU), as shown in this portion of the code (line 469 in conn.c) : LDAP_BACK_TV_SET( &tv ); retry:; rc = ldap_result( msc->msc_ld, msgid, LDAP_MSG_ALL, &tv, &res ); which uses : #define LDAP_BACK_RESULT_TIMEOUT (0) #define LDAP_BACK_RESULT_UTIMEOUT (100000) #define LDAP_BACK_TV_SET(tv) \ do { \ (tv)->tv_sec = LDAP_BACK_RESULT_TIMEOUT; \ (tv)->tv_usec = LDAP_BACK_RESULT_UTIMEOUT; \ } while ( 0 ) The timeout is then set to 100ms, which might be too low when the remote server is 'far'.

1 0

Re: (ITS#8077) unknown envflags keyword
by dieter＠dkluenter.de 11 Mar '15

11 Mar '15

Am Wed, 11 Mar 2015 10:01:28 -0700 schrieb Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, March 11, 2015 4:39 PM +0000 dieter(a)dkluenter.de > wrote: >=20 > > Full_Name: Dieter Kluenter > > Version: openldap-OPENLDAP_REL_ENG_2_4-ba9a739 > > OS: openSUSE-13.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.220.7.239) > > > > > > Testing OPENLDAP_REL_ENG_2_4 with back-mdb I get following error: > > > > [...] > > 5500605c line 38 (database mdb) > > 5500605c mdb_db_init: Initializing mdb database > > 5500605c line 39 (suffix "o=3Dhdk") > > 5500605c >>> dnPrettyNormal:3C3Co=3Dhdk> > > ... > > 5500605c line 43 (directory "/work/openldap/var/ldap/data") > > 5500605c line 45 (envflags {nometasync,writemap,mapasync}) >=20 > Why are your envflags in {}'s ? Because that is a standard slapd.conf in my test environment, but the same with and without curly brackets. -Dieter=20 --=20 Dieter Kl=C3=BCnter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53=C2=B037'09,95"N 10=C2=B008'02,42"E

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