openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(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

(ITS#8082) slapd leaks memory - using clang to do static analysis
by ludovic＠hirlimann.net 18 Mar '15

18 Mar '15

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

1 0

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

18 Mar '15

Fixed in ReOpenLDAP week ago. https://github.com/ReOpen/ReOpenLDAP/commit/6de52172bc0f8309dd00c329452213d… Leonid.

1 0

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

18 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 16 Mar '15

16 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 14 Mar '15

14 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 13 Mar '15

13 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

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