openldap-bugs

openldap-bugs@openldap.org

21001 discussions

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

(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 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

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