openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 29 May '12

29 May '12

This is a cryptographically signed message in MIME format. --------------ms010700080803040702000401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable quanah(a)zimbra.com wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: >=20 >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrat= or >> access already you have no business running it. >=20 > What in any way makes it administrative? You simply give it a password= to=20 > convert into whatever scheme for you. Where is the administrative=20 > requirement? Why shouldn't X user with some particular permissions int= o=20 > the database, but not the configuration, be able to run it to generate = a=20 > value? I concur with Quanah: I know many operational procedures where slappasswd= is just used to generate pre-hashed userPassword values. This usage is suppo= rted by DESCRIPTION in slappasswd(8). I also don't see a requirement for administrative access to slapd's config at all. Doesn't this ask for fully integrating SHA-2 password support into libraries/liblutil/passwd.c? Ciao, Michael. --------------ms010700080803040702000401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyOTE2NDYzOFowIwYJKoZIhvcNAQkEMRYE FE1pvmOeFeNxFwX+H8VmVvMDK6OWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAG+NichvhG0i4Tb18NExkCpBoGmzkaf3J/WSiwU5y01mEOEct8YvtixC3EdVlpVfKYOLb pKDGt2W6yNZySAEkQqZlWffWaYou3aJF5t/DjykuqpvBR0wNO1casY8OGAHMX1g0RicGIS12 30Ulk8vJTYQy3hMovlfztgHaEE7yI8Acem9ccJAuFoXbTCyDC47HcDf/pL4en6WGyMkyruhR 0vULseO+OUQ+LY+ic4C8qPXAtSnDrCPmUaOcns7Nz2cuZFgPe7dVt4NcXpsKXihy+PIag+Tz iiskIJ7u4iQaPFW2QBDZrmpa8UPCaWOy6KjtDDF8TNj5LwewODIJZ03kMAAAAAAAAA== --------------ms010700080803040702000401--

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by quanah＠zimbra.com 29 May '12

29 May '12

--On Tuesday, May 29, 2012 4:08 PM +0000 hyc(a)symas.com wrote: >> It is a problem that a slappasswd user must have read privilage >> on slapd.conf (or slapd.d) by this patch... > > slappasswd is an administrative command; if you don't have administrator > access already you have no business running it. What in any way makes it administrative? You simply give it a password to convert into whatever scheme for you. Where is the administrative requirement? Why shouldn't X user with some particular permissions into the database, but not the configuration, be able to run it to generate a value? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by hyc＠symas.com 29 May '12

29 May '12

fumiyas(a)osstech.co.jp wrote: > At Tue, 29 May 2012 05:49:52 GMT, > fumiyas@OSSTech wrote: >>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch >> >> In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. >> Sorry. > > FYI. > > [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules > https://gist.github.com/2632560 > > It is a problem that a slappasswd user must have read privilage > on slapd.conf (or slapd.d) by this patch... slappasswd is an administrative command; if you don't have administrator access already you have no business running it. -- -- 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#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 29 May '12

29 May '12

At Tue, 29 May 2012 05:49:52 GMT, fumiyas@OSSTech wrote: > > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch > > In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. > Sorry. FYI. [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules https://gist.github.com/2632560 It is a problem that a slappasswd user must have read privilage on slapd.conf (or slapd.d) by this patch... > > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > > to slapd-sha2 module. > > > > This patch depends on > > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.co.jp 29 May '12

29 May '12

At Thu, 24 May 2012 01:32:33 GMT, fumiyas@OSSTech wrote: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. Sorry. > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > to slapd-sha2 module. > > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7280) accesslog write to subentry of log database
by openldap＠stormcloud9.net 28 May '12

28 May '12

This is a multi-part message in MIME format. --------------060900070300040405040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <hyc(a)symas.com> To: openldap(a)stormcloud9.net openldap-its(a)openldap.org Subject: Re: (ITS#7280) accesslog write to subentry of log database > openldap(a)stormcloud9.net wrote: >> Full_Name: Patrick Hemmer >> Version: 2.4.31 >> OS: Linux RHEL6 >> URL: >> Submission from: (NULL) (98.211.220.204) >> >> >> This is a feature request (mostly). >> >> Currently the accesslog overlay is only capable of writing to the >> base DN of a >> log database, and not a subentry of that database. Specifying the DN >> to a >> specific subentry for the "logdb" parameter ends up writing to the >> base DN of >> the database instead. >> >> The main reason for this is so that multiple accesslog overlays can >> write to the >> same backend database, and not have to create a separate database for >> each >> overlay. Currently if you try to give multiple accesslog overlays the >> same >> database, it causes deadlock issues (or it appears to be a deadlock) >> and write >> operations end up hanging. I'm not sure if this should be considered >> a bug, or >> just noted as "don't try and do that". > > Don't do that. Closing this ITS. > This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick --------------060900070300040405040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000066"> Sent: Sun May 27 2012 19:02:08 GMT-0400 (EDT) From: Howard Chu <a class="moz-txt-link-rfc2396E" href="mailto:hyc@symas.com"><hyc(a)symas.com></a> To: <a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> Subject: Re: (ITS#7280) accesslog write to subentry of log database <blockquote cite="mid:4FC2B270.9090900@symas.com" type="cite"><a class="moz-txt-link-abbreviated" href="mailto:openldap@stormcloud9.net">openldap(a)stormcloud9.net</a> wrote: <blockquote type="cite">Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that". </blockquote> Don't do that. Closing this ITS. </blockquote> This is nonconstructive. I know not to do that, I'm the one who filed the ITS... You don't address the feature request at all, only that it currently doesn't work which is why the request was filed in the first place. Is logging multiple accesslog overlays to the same backend database unfeasible? -Patrick </body> </html> --------------060900070300040405040602--

1 0

Re: (ITS#7280) accesslog write to subentry of log database
by hyc＠symas.com 28 May '12

28 May '12

openldap(a)stormcloud9.net wrote: > Full_Name: Patrick Hemmer > Version: 2.4.31 > OS: Linux RHEL6 > URL: > Submission from: (NULL) (98.211.220.204) > > > This is a feature request (mostly). > > Currently the accesslog overlay is only capable of writing to the base DN of a > log database, and not a subentry of that database. Specifying the DN to a > specific subentry for the "logdb" parameter ends up writing to the base DN of > the database instead. > > The main reason for this is so that multiple accesslog overlays can write to the > same backend database, and not have to create a separate database for each > overlay. Currently if you try to give multiple accesslog overlays the same > database, it causes deadlock issues (or it appears to be a deadlock) and write > operations end up hanging. I'm not sure if this should be considered a bug, or > just noted as "don't try and do that". Don't do that. Closing this ITS. -- -- 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#7281) [cxx sasl] Gentoo build 2.4.31-r1 gcc-4.7 SaslInteractionHandler.cpp
by nheghathivhistha＠gmail.com 27 May '12

27 May '12

Full_Name: David Kredba Version: 2.4.31 OS: GNU/Linux-3.4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.112.13.17) make[2]: Entering directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' /bin/sh ../libtool --tag=CXX --mode=compile x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c -o SaslInteractionHandler.lo SaslInteractionHandler.cpp x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -O2 -pipe -ggdb -march=native -D_GNU_SOURCE -c SaslInteractionHandler.cpp -fPIC -DPIC -o .libs/SaslInteractionHandler.o SaslInteractionHandler.cpp: In member function ‘virtual void DefaultSaslInteractionHandler::handleInteractions(const std::list<SaslInteraction*>&)’: SaslInteractionHandler.cpp:56:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:67:27: error: ‘STDIN_FILENO’ was not declared in this scope SaslInteractionHandler.cpp:85:23: error: ‘STDIN_FILENO’ was not declared in this scope make[2]: *** [SaslInteractionHandler.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make: *** [all-recursive] Error 1 * ERROR: net-nds/openldap-2.4.31-r1 failed (compile phase): * emake failed I tried to add someof Google suggested header files (unistd.h etc) but no luck. Thank you.

1 0

Re: (ITS#7277) Slapadd segfaults if binddn contains ou or dc statements
by quanah＠zimbra.com 27 May '12

27 May '12

--On Monday, May 21, 2012 5:27 PM +0000 o.loch(a)gmx.net wrote: > > --Apple-Mail=_E91EDB34-885C-4527-B3A7-0CF927EAA88D > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=iso-8859-1 > > Hello, > > thanks for the reply. I followed your advice and played a bit with it = > and now it's working. > > It's interesting that you always have to include the core.schema even if = > you use a replicated config. <http://dictionary.reference.com/browse/core?s=t> noun 2. the central, innermost, or most essential part of anything. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7280) accesslog write to subentry of log database
by openldap＠stormcloud9.net 25 May '12

25 May '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: Linux RHEL6 URL: Submission from: (NULL) (98.211.220.204) This is a feature request (mostly). Currently the accesslog overlay is only capable of writing to the base DN of a log database, and not a subentry of that database. Specifying the DN to a specific subentry for the "logdb" parameter ends up writing to the base DN of the database instead. The main reason for this is so that multiple accesslog overlays can write to the same backend database, and not have to create a separate database for each overlay. Currently if you try to give multiple accesslog overlays the same database, it causes deadlock issues (or it appears to be a deadlock) and write operations end up hanging. I'm not sure if this should be considered a bug, or just noted as "don't try and do that".

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