- openldap-bugs - openldap.org

Re: (ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

On 07/07/15 21:44, h.b.furuseth(a)usit.uio.no wrote: > My feeling is that this is a quirk the user should not need to > know about, and it's cleaner to sy r rather than to document it. ...cleaner to sync rather than...

1 0

(ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_txn_commit(txn which made no changes) does not mdb_env_sync(), but lmdb.h says several times that Commit flushes buffers to disk. My feeling is that this is a quirk the user should not need to know about, and it's cleaner to sy r rather than to document it. OTOH I don't know if "fast commit of no-change txns" is a feature which someone expects to work, and if sync can be expensive even when there is no new data to flush. (I don't know what BDB does.)

1 0

(ITS#8190) LMDB cursor bug
by hyc＠openldap.org 07 Jul '15

07 Jul '15

Full_Name: Howard Chu Version: LMDB 0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.234.0) Submitted by: hyc In mdb_cursor_set(SET_RANGE) a call to mdb_cursor_sibling is used if the matching key wasn't found on the current page. If this call fails, the EOF flag should be set on the cursor but isn't. Subsequent attempts to call mdb_cursor_next() will read garbage data. A fix is coming shortly.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

On 07/06/2015 01:30 PM, Michael Ströder wrote: > Consider that you are under on-going attack with many different > accounts affected by the lockout treshold. Then you cannot simply wait > for pwdFailureCountInterval seconds because your system is changing > all the time. > > Such a situation is a real world scenario. Ok -- I'm probably not understanding enough about your particular scenario to fully appreciate the concerns that you express. But I think there could be ways to address them in this enhancement -- for instance, by adding optional parameter(s) like ppolicy_purge_failures <nfailures> and/or ppolicy_purge_olderthan <timestamp>, which could then be configured to accommodate the scenario you describe. At this point, I'll think I'll leave it up to the OpenLDAP developers as to how they want to proceed on this, and/or to ask for more information. Thanks for the discussion Michael. Regards, -Kartik

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 06 Jul '15

06 Jul '15

Kartik Subbarao wrote: > On 07/06/2015 12:25 PM, Michael Str=C3=B6der wrote: >> Hmm, still have some doubts: If you want to raise the failure count li= mit >> later you would automatically unlock some accounts you don't want to u= nlock >> at this particular point in time. >=20 > Two thoughts on this: >=20 > 1) If you raise the failure count limit, aren't you inherently making a= > decision to be more lenient in your policy, and thereby accepting that = some > accounts are not going to be locked out as fast as they might be under = the > previous policy? Yes, there could be a situation where you want to deliberately relax the lockout policy after carefully considering various security aspects of yo= ur particular deployment. > It seems to me that any "inadvertent" unlocking due to purged > pwdFailureTime values could be embraced under this general umbrella of = leniency. No! You set a new lockout limit and most people would expect this to be s= olely effective on user accounts which did not reach the new limit yet. > 2) If pwdFailureCountInterval is set to some reasonably low number, the= n this > whole concern becomes moot: Just wait for pwdFailureCountInterval secon= ds > after you decide to change the configuration, before actually changing = the > configuration :-) Consider that you are under on-going attack with many different accounts affected by the lockout treshold. Then you cannot simply wait for pwdFailureCountInterval seconds because your system is changing all the t= ime. Such a situation is a real world scenario. =3D> @OpenLDAP developers: leave as is! Ciao, Michael. P.S.: I'm not a big fan of password lockout anyway because it's misconfig= ured too often because of brain-dead comapny security policies.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

Thanks for the heads-up Quanah. Looks like you've found a serious problem with multi-master replication, good to know about. In my case, we're just using single-master replication, so we're able to dodge the problem you describe for the time being. Just to clarify though -- once ITS#8125 is resolved, this enhancement shouldn't pose any additional problems for MMR sites, right? Thanks, -Kartik On 07/06/2015 12:18 PM, Quanah Gibson-Mount wrote: > I would note that: > > IF using delta-syncrepl > AND the data values are replicated > AND authentication attempts can occur against different LDAP masters > > You can run into *serious* drift between servers if you try and > implement this, causing endless refresh mode runs that cause the > servers to get further out of sync. See > <http://www.openldap.org/its/index.cgi/?findid=8125>. > > More specifically: > > If a client has (most often) a mobile device with a bad password, and > it's authentication attempts are bouncing between masters, even with > high resolution timestamps, you can get collisions in the delete op > for old values that cannot be reconciled, causing fallback/refresh. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

This is a multi-part message in MIME format. --------------000605000401060905080908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/06/2015 12:25 PM, Michael Ströder wrote: > Hmm, still have some doubts: If you want to raise the failure count limit > later you would automatically unlock some accounts you don't want to unlock at this particular point in time. Two thoughts on this: 1) If you raise the failure count limit, aren't you inherently making a decision to be more lenient in your policy, and thereby accepting that some accounts are not going to be locked out as fast as they might be under the previous policy? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency. 2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-) I guess I haven't come across many sites that set pwdMaxFailure, but /don't/ also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-) Regards, -Kartik --------------000605000401060905080908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 07/06/2015 12:25 PM, Michael Ströder wrote: </div> <blockquote cite="mid:559AABDC.8060706@stroeder.com" type="cite"> <pre wrap=""> Hmm, still have some doubts: If you want to raise the failure count limit later you would automatically unlock some accounts you don't want to unlock at this particular point in time. </pre> </blockquote> Two thoughts on this: 1) If you raise the failure count limit, aren't you inherently making a decision to be more lenient in your policy, and thereby accepting that some accounts are not going to be locked out as fast as they might be under the previous policy? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency. 2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-) I guess I haven't come across many sites that set pwdMaxFailure, but don't also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-) Regards, -Kartik </body> </html> --------------000605000401060905080908--

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

This is a multi-part message in MIME format. --------------070603090603020704050207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI for anyone else who is encountering this problem -- here is a script that I wrote as a workaround. It sweeps through all of the pwdFailureTime entries in the directory and deletes stale values greater than $maxvalues. Also set $basedn accordingly. It can be run with '--ldif' to preview the changes, and '--ldap' to actually make the changes. The script binds with SASL EXTERNAL on the ldapi:/// interface, so make sure that the Unix user has the 'manage' privilege for the pwdFailureTime attribute. For example, to enable this for root: access to attrs=pwdFailureTime by dn.base="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" manage Regards, -Kartik --------------070603090603020704050207 Content-Type: text/plain; charset=UTF-8; name="pwdfailuretime.pl.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pwdfailuretime.pl.txt" IyEgL3Vzci9iaW4vcGVybAoKIyBQdXJnZSBzdGFsZSBwd2RGYWlsdXJlVGltZSB2YWx1ZXMK CnVzZSBOZXQ6OkxEQVA7CnVzZSBOZXQ6OkxEQVA6OkNvbnRyb2w7CnVzZSBOZXQ6OkxEQVA6 OkxESUY7CnVzZSBBdXRoZW46OlNBU0w7CnVzZSBGY250bCBxdyhMT0NLX0VYIExPQ0tfTkIp Owp1c2UgR2V0b3B0OjpMb25nOwoKdXNlIHN0cmljdDsKCm15ICRiYXNlZG4gPSAiZGM9ZXhh bXBsZSxkYz1jb20iOwpteSAkbWF4dmFsdWVzID0gMTA7CgojIFByZXZlbnQgbXVsdGlwbGUg aW5zdGFuY2VzIGZyb20gcnVubmluZyBhdCB0aGUgc2FtZSB0aW1lCm9wZW4oTE9DS0ZILCAk MCk7IGZsb2NrKExPQ0tGSCwgTE9DS19FWHxMT0NLX05CKSBvciBleGl0IDE7CgpteSAoJGdl bmVyYXRlX2xkaWYsICR1cGRhdGVfbGRhcCk7CkdldE9wdGlvbnMoJ2xkaWYnID0+IFwkZ2Vu ZXJhdGVfbGRpZiwgJ2xkYXAnID0+IFwkdXBkYXRlX2xkYXApOwoKbXkgJGxkaWZvdXQgPSBO ZXQ6OkxEQVA6OkxESUYtPm5ldygnLScsICd3Jyk7CiRsZGlmb3V0LT57Y2hhbmdlfSA9IDE7 Cm15ICRsZGFwID0gTmV0OjpMREFQLT5uZXcoJ2xkYXBpOi8vJykgb3IgZGllICJsZGFwaTog JEBcbiI7Cm15ICRzYXNsID0gQXV0aGVuOjpTQVNMLT5uZXcobWVjaGFuaXNtID0+ICdFWFRF Uk5BTCcpOwpteSAkc2FzbF9jbGllbnQgPSAkc2FzbC0+Y2xpZW50X25ldygnbGRhcCcsICds b2NhbGhvc3QnKTsKJGxkYXAtPmJpbmQodW5kZWYsIHNhc2wgPT4gJHNhc2xfY2xpZW50KTsK bXkgJHJlbGF4ID0gTmV0OjpMREFQOjpDb250cm9sLT5uZXcodHlwZSA9PiAnMS4zLjYuMS40 LjEuNDIwMy42NjYuNS4xMicpOwoKbXkgJG1lc2cgPSAkbGRhcC0+c2VhcmNoKGJhc2UgPT4g JGJhc2VkbiwKCQkJCQkJIGZpbHRlciA9PiAnKHB3ZEZhaWx1cmVUaW1lPSopJywKCQkJCQkJ IGF0dHJzID0+IFsncHdkRmFpbHVyZVRpbWUnXSk7CiRtZXNnLT5jb2RlICYmIGRpZSgkbWVz Zy0+ZXJyb3IgLiAiXG4iKTsKZm9yZWFjaCBteSAkZW50cnkgKCRtZXNnLT5lbnRyaWVzKSB7 CglteSBAdmFsdWVzID0gc29ydCAkZW50cnktPmdldF92YWx1ZSgncHdkRmFpbHVyZXRpbWUn KTsKCW5leHQgaWYgQHZhbHVlcyA8PSAkbWF4dmFsdWVzOwoJIyBTZXQgQHZhbHVlcyB0byB0 aGUgbGlzdCBvZiB2YWx1ZXMgdG8gcHVyZ2UKCXNwbGljZSBAdmFsdWVzLCAtJG1heHZhbHVl czsKCWlmICgkZ2VuZXJhdGVfbGRpZikgewoJCSRlbnRyeS0+ZGVsZXRlKCdwd2RGYWlsdXJl dGltZScgPT4gXEB2YWx1ZXMpOwoJCSRsZGlmb3V0LT53cml0ZV9lbnRyeSgkZW50cnkpOwoJ fQoJaWYgKCR1cGRhdGVfbGRhcCkgewoJCSRsZGFwLT5tb2RpZnkoJGVudHJ5LT5kbiwKCQkJ CQkgIGNvbnRyb2wgPT4gJHJlbGF4LAoJCQkJCSAgZGVsZXRlID0+IHsgcHdkRmFpbHVyZXRp bWUgPT4gXEB2YWx1ZXMgfSk7Cgl9Cn0K --------------070603090603020704050207--

1 0

Re: (ITS#8189) autoconf needed when building release
by michael＠stroeder.com 06 Jul '15

06 Jul '15

checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... none configure: error: Unknown Berkeley DB major version in db.h >From config.log: configure:20300: checking db.h usability configure:20300: cc -c -g -O0 -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES -DSLAP_CONFIG_DELETE -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c >&5 configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking db.h presence configure:20300: cc -E -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking for db.h configure:20300: result: yes configure:20311: checking for Berkeley DB major version in db.h configure:20331: result: none configure:20334: error: Unknown Berkeley DB major version in db.h

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 06 Jul '15

06 Jul '15

This is a cryptographically signed message in MIME format. --------------ms000206000000020208060300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kartik Subbarao wrote: > You mention that "pwdFailureTime is also used as a failure lockout coun= ter". I > don't see how that conflicts with what I am requesting. I'm only asking= for > /excess/ pwdFailureTime values that are above the pwdMaxFailure count t= o be > purged. Oh, I see. Indeed I did not fully understand your original message. > For example, if pwdMaxFailure is 3, and pwdFailureTime has the > following values: >=20 > pwdFailureTime: 20150702184821Z > pwdFailureTime: 20150702185821Z > pwdFailureTime: 20150702190822Z > pwdFailureTime: 20150702191007Z > pwdFailureTime: 20150702191012Z >=20 > What I'm requesting is that the /oldest/ two values be deleted from thi= s set: Hmm, still have some doubts: If you want to raise the failure count limit= later you would automatically unlock some accounts you don't want to unlo= ck at this particular point in time. Ciao, Michael. --------------ms000206000000020208060300 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwNjE2MjUwMFowLwYJKoZIhvcNAQkEMSIE IH7+cZbIVOCGL55ZjKKaUB/HHprnj2PhEJuxySRq8xP/MGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQAYG+byNJRgIHP9toZH8tn2UbQgnS24FVS+UMsGsFfpaITB5HECe9wH hJnCbzGUBE7YIXOKXCqSPbv5O+p9oj8IfP9Go80R8Gemrx3/MdnaxGGBDkvBLLlyrRhvVfTm a0MKEuwXrTMeAmf33hmAeMtJxdYJj8ibRO4HWf1rsivzIjnvyajdVvCjEWKhHk8l5u6D3icw 7ufZtt6B49R3gaYaE072rp+5r9iENwgwF60RacNGTMfjtSlNCN3WHEbIq9Eys1EZ5BKaBc44 VcYKDP1zoqe4QXoxxJ85uFySM6AScLAod0el8Z9GXNwe7m795l6lIgeY0dye7HBTWMJUteTD AAAAAAAA --------------ms000206000000020208060300--

1 0

(ITS#8189) autoconf needed when building release
by michael＠stroeder.com 06 Jul '15

06 Jul '15

Full_Name: Version: 2.4.41 OS: URL: Submission from: (NULL) (79.223.59.125) It's currently necessary to run autoconf before configure to build with gcc-5.1.1. Otherwise cpp is not invoked with -P and thus the Berkeley DB check fails.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by quanah＠zimbra.com 06 Jul '15

06 Jul '15

--On Monday, July 06, 2015 5:12 PM +0000 subbarao(a)computer.org wrote: > This is a multi-part message in MIME format. > --------------060309030709060507050000 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hi Michael, > > I'm having a bit of difficulty understanding your response, and it looks > like my initial message was perhaps equally as unclear to you :-) Let me > try to clarify, please let me know if this still doesn't make sense. > > You mention that "pwdFailureTime is also used as a failure lockout > counter". I don't see how that conflicts with what I am requesting. I'm > only asking for /excess/ pwdFailureTime values that are above the > pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3, > and pwdFailureTime has the following values: > > pwdFailureTime: 20150702184821Z > pwdFailureTime: 20150702185821Z > pwdFailureTime: 20150702190822Z > pwdFailureTime: 20150702191007Z > pwdFailureTime: 20150702191012Z I would note that: IF using delta-syncrepl AND the data values are replicated AND authentication attempts can occur against different LDAP masters You can run into *serious* drift between servers if you try and implement this, causing endless refresh mode runs that cause the servers to get further out of sync. See <http://www.openldap.org/its/index.cgi/?findid=8125>. More specifically: If a client has (most often) a mobile device with a bad password, and it's authentication attempts are bouncing between masters, even with high resolution timestamps, you can get collisions in the delete op for old values that cannot be reconciled, causing fallback/refresh. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

This is a multi-part message in MIME format. --------------060309030709060507050000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, I'm having a bit of difficulty understanding your response, and it looks like my initial message was perhaps equally as unclear to you :-) Let me try to clarify, please let me know if this still doesn't make sense. You mention that "pwdFailureTime is also used as a failure lockout counter". I don't see how that conflicts with what I am requesting. I'm only asking for /excess/ pwdFailureTime values that are above the pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3, and pwdFailureTime has the following values: pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z pwdFailureTime: 20150702190822Z pwdFailureTime: 20150702191007Z pwdFailureTime: 20150702191012Z What I'm requesting is that the /oldest/ two values be deleted from this set: pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z (To be more precise, I'll suggest that when ppolicy_bind_response() processes the BIND failure that triggers the addition of 20150702191012Z to pwdFailureTime, that's when it could delete the two oldest values. It already loops through the entire set of pwdFailureTime values, so adding a check to delete older ones above the pwdMaxFailure count could be done in that same loop). I'm not seeing how this would conflict with the password policy specification -- am I missing something? In the particular situation that's prompting this request, it's not just two or three values -- for one entry it was over 38000 values that had accumulated over time! (and generally high values for many other entries). ITS#7161 doesn't address this issue -- it adds more precision to the timestamp values, but it doesn't purge excess stale values. Here's how this issue relates to ITS#7089. In ITS#7089, the requester was seeing failed bind attempts to entries that didn't have a password defined. As a result, pwdFailureTime values were consistently being added to these entries. The common theme is that there is no built-in way (to my knowledge) in OpenLDAP to protect against pwdFailureTime values continually being added to entries indefinitely. This enhancement would mitigate that problem by putting a cap on the number of pwdFailureTime attributes that could ever accumulate on an entry -- the pwdMaxFailure count. Just like administrators have control over expiring old log files, they would get the ability to ensure that pwdFailureTime values couldn't accumulate indefinitely. Please let me know what you think. Thanks, -Kartik Michael Stroeder wrote: >> This wording in the slapo-ppolicy man page sounds friendly towards this >> interpretation: "Excess timestamps beyond those allowed by pwdMaxFailure >> may also be purged." >> >> Looking at the source code though, it doesn't seem that pwdFailureTime >> values are actually removed unless a successful bind occurs -- whereupon >> all values of course are removed. >> >> I would like to request an enhancement to purge stale pwdFailureTime >> values as mentioned above. > > Nope. The number of pwdFailureTime is also used as failure lockout > counter. Actually it was improved with ITS#7161. > >> This would also largely mitigate the issue raised in ITS#7089 > > I don't see the relation with ITS#7089. --------------060309030709060507050000 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Michael, I'm having a bit of difficulty understanding your response, and it looks like my initial message was perhaps equally as unclear to you :-) Let me try to clarify, please let me know if this still doesn't make sense. You mention that "pwdFailureTime is also used as a failure lockout counter". I don't see how that conflicts with what I am requesting. I'm only asking for excess pwdFailureTime values that are above the pwdMaxFailure count to be purged. For example, if pwdMaxFailure is 3, and pwdFailureTime has the following values: pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z pwdFailureTime: 20150702190822Z pwdFailureTime: 20150702191007Z pwdFailureTime: 20150702191012Z What I'm requesting is that the oldest two values be deleted from this set: pwdFailureTime: 20150702184821Z pwdFailureTime: 20150702185821Z (To be more precise, I'll suggest that when ppolicy_bind_response() processes the BIND failure that triggers the addition of 20150702191012Z to pwdFailureTime, that's when it could delete the two oldest values. It already loops through the entire set of pwdFailureTime values, so adding a check to delete older ones above the pwdMaxFailure count could be done in that same loop). I'm not seeing how this would conflict with the password policy specification -- am I missing something? In the particular situation that's prompting this request, it's not just two or three values -- for one entry it was over 38000 values that had accumulated over time! (and generally high values for many other entries). ITS#7161 doesn't address this issue -- it adds more precision to the timestamp values, but it doesn't purge excess stale values. Here's how this issue relates to ITS#7089. In ITS#7089, the requester was seeing failed bind attempts to entries that didn't have a password defined. As a result, pwdFailureTime values were consistently being added to these entries. The common theme is that there is no built-in way (to my knowledge) in OpenLDAP to protect against pwdFailureTime values continually being added to entries indefinitely. This enhancement would mitigate that problem by putting a cap on the number of pwdFailureTime attributes that could ever accumulate on an entry -- the pwdMaxFailure count. Just like administrators have control over expiring old log files, they would get the ability to ensure that pwdFailureTime values couldn't accumulate indefinitely. Please let me know what you think. Thanks, -Kartik Michael Stroeder wrote: >> This wording in the slapo-ppolicy man page sounds friendly towards this >> interpretation: "Excess timestamps beyond those allowed by pwdMaxFailure >> may also be purged." >> >> Looking at the source code though, it doesn't seem that pwdFailureTime >> values are actually removed unless a successful bind occurs -- whereupon >> all values of course are removed. >> >> I would like to request an enhancement to purge stale pwdFailureTime >> values as mentioned above. > > Nope. The number of pwdFailureTime is also used as failure lockout > counter. Actually it was improved with ITS#7161. > >> This would also largely mitigate the issue raised in ITS#7089 > > I don't see the relation with ITS#7089. </body> </html> --------------060309030709060507050000--

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 06 Jul '15

06 Jul '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, below you will find the slapd.conf of the OpenLDAP Proxy and the slapd.conf= of the OpenLDAP Master where you can see which overlays we are using. The debug symbol core dump we will provide asap, we need first install the = debug packages for that on one host. OpenLDAP Proxy slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/guacConfigGroup.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap moduleload back_ldap.la moduleload auditlog overlay auditlog auditlog /var/lib/ldap/auditlog/ldap.auditlog TLSCertificateFile /etc/openldap/ssl.crt/server.crt TLSCertificateKeyFile /etc/openldap/ssl.key/server.key TLSCACertificatePath /etc/openldap/ssl.crt/ TLSCipherSuite HIGH:MEDIUM:-SSLv2 TLSVerifyClient allow security ssf=3D112 update_ssf=3D112 tls=3D56 loglevel stats none sizelimit unlimited database ldap protocol-version 3 tls start suffix "dc=3Dxxxx.xx" uri "ldap://xxxx.xx.xxx.xx.xx:389/" idassert-authzFrom "*" idle-timeout 1500 idletimeout 2700 And here the OpenLDAP Master slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/sudo.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules TLSCertificateFile /etc/openldap/ssl.crt/server.crt TLSCertificateKeyFile /etc/openldap/ssl.key/server.key TLSCACertificatePath /etc/openldap/ssl.crt/ TLSCipherSuite HIGH:MEDIUM:-SSLv2 TLSVerifyClient allow security ssf=3D112 update_ssf=3D112 tls=3D56 password-hash {SHA} loglevel stats sync none include /etc/openldap/slapd.access sizelimit unlimited database hdb readonly off suffix "dc=3Dxxx.xx" rootdn "cn=3DManager,dc=3Dxxx.xx" rootpw {SSHA}xxxxxxxxxx directory /var/lib/ldap/ checkpoint 1024 5 cachesize 100000 idlcachesize 100000 index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid eq index uidNumber pres,eq index gidNumber pres,eq index uniqueMember pres,eq index memberOf pres,eq index sudoUser pres,eq,sub index entryCSN,entryUUID eq index mail pres,eq,sub index userClass pres,eq index ipHostNumber eq overlay unique unique_uri ldap:///?uid?sub overlay ppolicy ppolicy_default "cn=3Dxxxx,ou=3Dxxxxx,dc=3Dxxxx,dc=3Dxxxx.xx" ppolicy_use_lockout overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniqueMember memberof-refint true memberof-dn cn=3DMemberOfOverlay,dc=3Dxxx.xx overlay auditlog auditlog /var/lib/ldap/auditlog/ldap.auditlog database monitor best Regards Adrian --_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p> <o:p> </o:p> below you will find the slapd.c= onf of the OpenLDAP Proxy and the slapd.conf of the OpenLDAP Master where y= ou can see which overlays we are using.<o:p></o:p> The debug symbol core dump we w= ill provide asap, we need first install the debug packages for that on one = host. <o:p></o:p> <o:p> </o:p> OpenLDAP Proxy slapd.conf:<o:p>= </o:p> <o:p> </o:p> include    =       /etc/openldap/schema/core.schema<o:p></o:p><= /span> include    =       /etc/openldap/schema/cosine.schema<o:p></o:p= > include    =      /etc/openldap/schema/inetorgperson.schema<o:= p></o:p> include    =       /etc/openldap/schema/openldap.schema<o:p></o= :p> include    =       /etc/openldap/schema/rfc2307bis.schema<o:p><= /o:p> include    =       /etc/openldap/schema/ppolicy.schema<o:p></o:= p> include    =       /etc/openldap/schema/sudo.schema<o:p></o:p><= /span> include    =       /etc/openldap/schema/guacConfigGroup.schema<= o:p></o:p> <o:p> </o:p> pidfile    =       /var/run/slapd/slapd.pid<o:p></o:p></= p> argsfile   &nbsp= ;     /var/run/slapd/slapd.args<o:p></o:p> <o:p> </o:p> modulepath    /u= sr/lib/openldap<o:p></o:p> moduleload    ba= ck_ldap.la<o:p></o:p> moduleload   &nb= sp;  auditlog<o:p></o:p> overlay    =      auditlog<o:p></o:p> auditlog   &nbsp= ;    /var/lib/ldap/auditlog/ldap.auditlog<o:p></o:p><= /p> <o:p> </o:p> TLSCertificateFile  &= nbsp;  /etc/openldap/ssl.crt/server.crt<o:p></o:p> TLSCertificateKeyFile  /et= c/openldap/ssl.key/server.key<o:p></o:p> TLSCACertificatePath &nbsp= ; /etc/openldap/ssl.crt/<o:p></o:p> TLSCipherSuite  &nbsp= ;      HIGH:MEDIUM:-SSLv2<o:p></o:p> TLSVerifyClient  &nbs= p;     allow<o:p></o:p> <o:p> </o:p> security ssf=3D112 update_ssf= =3D112 tls=3D56<o:p></o:p> <o:p> </o:p> loglevel   &nbsp= ;    stats none<o:p></o:p> <o:p> </o:p> sizelimit   &nbs= p;   unlimited<o:p></o:p> <o:p> </o:p> database   &nbsp= ;     ldap<o:p></o:p> <o:p> </o:p> protocol-version  &nb= sp; 3<o:p></o:p> tls    &nbs= p;             =   start<o:p></o:p> suffix    &= nbsp;         "dc=3Dxxxx.xx&qu= ot;<o:p></o:p> uri    &nbs= p;             =  "ldap://xxxx.xx.xxx.xx.xx:389/"<o:p></o:p> idassert-authzFrom  "= *"<o:p></o:p> <o:p> </o:p> idle-timeout   &= nbsp;    1500<o:p></o:p> <o:p> </o:p> idletimeout   &n= bsp;     2700<o:p></o:p> <div style=3D"mso-element:para-border-div;border:none;border-bottom:solid w= indowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm"> <o:p> </o:p> </div> <o:p> </o:p> And here the OpenLDAP Master sl= apd.conf<o:p></o:p> <o:p> </o:p> include    =       /etc/openldap/schema/core.schema<o:p></o:p><= /span> include    =       /etc/openldap/schema/cosine.schema<o:p></o:p= > include    =       /etc/openldap/schema/inetorgperson.schema<o:= p></o:p> include    =       /etc/openldap/schema/openldap.schema<o:p></o= :p> include    =       /etc/openldap/schema/rfc2307bis.schema<o:p><= /o:p> include    =       /etc/openldap/schema/ppolicy.schema<o:p></o:= p> include    =       /etc/openldap/schema/sudo.schema<o:p></o:p><= /span> <o:p> </o:p> pidfile    &nbsp= ;     /var/run/slapd/slapd.pid<o:p></o:p></= p> argsfile   &nbsp= ;     /var/run/slapd/slapd.args<o:p></o:p> <o:p> </o:p> modulepath   &nb= sp;   /usr/lib/openldap/modules<o:p></o:p> <o:p> </o:p> TLSCertificateFile  &= nbsp;  /etc/openldap/ssl.crt/server.crt<o:p></o:p> TLSCertificateKeyFile  /et= c/openldap/ssl.key/server.key<o:p></o:p> TLSCACertificatePath &nbsp= ; /etc/openldap/ssl.crt/<o:p></o:p> TLSCipherSuite  &nbsp= ;      HIGH:MEDIUM:-SSLv2<o:p></o:p> TLSVerifyClient  &nbs= p;     allow<o:p></o:p> <o:p> </o:p> security ssf=3D112 update_ssf= =3D112 tls=3D56<o:p></o:p> <o:p> </o:p> password-hash {SHA}<o:p></o:p><= /span> <o:p> </o:p> loglevel   &nbsp= ;    stats sync none<o:p></o:p> <o:p> </o:p> include    =      /etc/openldap/slapd.access<o:p></o:p> <o:p> </o:p> sizelimit   &nbs= p;   unlimited<o:p></o:p> <o:p> </o:p> database   &nbsp= ;     hdb<o:p></o:p> <o:p> </o:p> readonly   &nbsp= ;     off<o:p></o:p> suffix    &= nbsp;      "dc=3Dxxx.xx"<o:p></o:p></spa= n> rootdn    &= nbsp;      "cn=3DManager,dc=3Dxxx.xx"<o:= p></o:p> rootpw    &= nbsp;      {SSHA}xxxxxxxxxx<o:p></o:p> directory   &nbs= p;    /var/lib/ldap/<o:p></o:p> checkpoint   &nb= sp;   1024 5<o:p></o:p> cachesize   &nbs= p;    100000<o:p></o:p> idlcachesize   &= nbsp; 100000<o:p></o:p> <o:p> </o:p> index objectClass  &n= bsp;        eq<o:p></o:p> index cn   &nbsp= ;            &n= bsp;   pres,sub,eq<o:p></o:p> index sn   &nbsp= ;            &n= bsp;   pres,sub,eq<o:p></o:p> index uid   &nbs= p;            &= nbsp;  eq<o:p></o:p> index uidNumber  &nbs= p;          pres,eq<o:p></o:p>= index gidNumber  &nbs= p;          pres,eq<o:p></o:p>= index uniqueMember  &= nbsp;       pres,eq<o:p></o:p> index memberOf  &nbsp= ;           pres,eq<o:p><= /o:p> index sudoUser  &nbsp= ;           pres,eq,sub<o= :p></o:p> index entryCSN,entryUUID &= nbsp;  eq<o:p></o:p> index mail   &nb= sp;            =   pres,eq,sub<o:p></o:p> index userClass  &nbs= p;          pres,eq<o:p></o:p>= index ipHostNumber  &= nbsp;       eq<o:p></o:p> <o:p> </o:p> overlay unique<o:p></o:p></span= > unique_uri ldap:///?uid?sub<o:p= ></o:p> <o:p> </o:p> overlay    =          ppolicy<o:p></o:p><= /p> ppolicy_default  &nbs= p;  "cn=3Dxxxx,ou=3Dxxxxx,dc=3Dxxxx,dc=3Dxxxx.xx"<o:p></o:p>= ppolicy_use_lockout<o:p></o:p><= /span> <o:p> </o:p> overlay    =          memberof<o:p></o:p>= memberof-group-oc   g= roupOfUniqueNames<o:p></o:p> memberof-member-ad  unique= Member<o:p></o:p> memberof-refint  &nbs= p;  true<o:p></o:p> memberof-dn   &n= bsp;     cn=3DMemberOfOverlay,dc=3Dxxx.xx<o:p></o:p></s= pan> <o:p> </o:p> overlay    =          auditlog<o:p></o:p>= auditlog   &nbsp= ;        /var/lib/ldap/auditlog/ldap.aud= itlog<o:p></o:p> <o:p> </o:p> database   &nbsp= ;        monitor<o:p></o:p> <o:p> </o:p> best Regards<o:p></o:p><= /p> Adrian<o:p></o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A2799ABEREXMBX19ifc1i_--

1 0

(ITS#8188) unable to see the users on client after importing the TLS certificate
by vijeshkrishna＠yahoo.com 03 Jul '15

03 Jul '15

Full_Name: Vijesh Version: 2.4 OS: RHEL 6.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.219.201.69) Hello Team, thank you for OpenLDAP. i am condiguring a new LDAP server. have updated all the mandatory details and added users to redhat and then imported to LDAP. i can see the user names in slapcat o/p. but unable to login or see via getent passwd. Could you help me on this instance please. much appreciate your help. dn: uid=vijesh,ou=People,dc=autozone,dc=com uid: vijesh cn: vijesh sn: vijesh mail: vijesh(a)autozone.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e2NyeXB0fSQ2JGM0MzF4WmpqJDRHUGlpOWZOb2tOMGNyQzI1OW84YmRPREtKQkF kSkt6ZFZaNXFUWWYwLjNHTVNyc2RnLy5OcVJ1M2s4UExOdC9TZ3FKTUl4WmxsdHk1V1FFaU0vUW4x shadowLastChange: 16618 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 504 gidNumber: 504 homeDirectory: /home/vijesh structuralObjectClass: inetOrgPerson entryUUID: 1c742176-b525-1034-9cce-db949f9d492f creatorsName: cn=Manager,dc=autozone,dc=com createTimestamp: 20150702164245Z entryCSN: 20150702164245.974424Z#000000#000#000000 modifiersName: cn=Manager,dc=autozone,dc=com modifyTimestamp: 20150702164245Z dn: cn=vijesh,ou=MC,dc=autozone,dc=com objectClass: posixGroup objectClass: top cn: vijesh userPassword:: e2NyeXB0fXg= gidNumber: 504 structuralObjectClass: posixGroup entryUUID: 2ae69360-b525-1034-9ccf-db949f9d492f creatorsName: cn=Manager,dc=autozone,dc=com createTimestamp: 20150702164310Z entryCSN: 20150702164310.212553Z#000000#000#000000 modifiersName: cn=Manager,dc=autozone,dc=com modifyTimestamp: 20150702164310Z dn: dc=autozone,dc=com dc: autozone objectClass: top objectClass: domain objectClass: domainRelatedObject associatedDomain: autozone.com structuralObjectClass: domain entryUUID: 26091f28-b3bf-1034-8106-b1690628f900 creatorsName: cn=Manager,dc=autozone,dc=com createTimestamp: 20150630220022Z entryCSN: 20150630220022.221149Z#000000#000#000000 modifiersName: cn=Manager,dc=autozone,dc=com modifyTimestamp: 20150630220022Z dn: ou=Hosts,dc=autozone,dc=com ou: Hosts objectClass: top objectClass: organizationalUnit objectClass: domainRelatedObject associatedDomain: autozone.com structuralObjectClass: organizationalUnit entryUUID: 2615b6ac-b3bf-1034-8107-b1690628f900 creatorsName: cn=Manager,dc=autozone,dc=com createTimestamp: 20150630220022Z entryCSN: 20150630220022.303673Z#000000#000#000000 modifiersName: cn=Manager,dc=autozone,dc=com modifyTimestamp: 20150630220022Z [root@DL380g5i2u34 /]# authconfig-tui Starting sssd: [ OK ] Stopping nslcd: [ OK ] [root@DL380g5i2u34 /]# ps -ef |grep -i sssd root 14849 1 0 00:51 ? 00:00:00 /usr/sbin/sssd -f -D root 14851 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_be -d 0 --debug-to-files --domain default root 14855 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_nss -d 0 --debug-to-files root 14856 14849 0 00:51 ? 00:00:00 /usr/libexec/sssd/sssd_pam -d 0 --debug-to-files root 14869 8260 0 00:51 pts/0 00:00:00 grep -i sssd [root@DL380g5i2u34 /]# su - user1 su: user user1 does not exist [root@DL380g5i2u34 /]# su - vijesh su: user vijesh does not exist [root@DL380g5i2u34 /]# please let me know if you need any additional information? thank you, Vijesh

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 03 Jul '15

03 Jul '15

This is a cryptographically signed message in MIME format. --------------ms040304010104090205010307 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable subbarao(a)computer.org wrote: > Reading the slapo-ppolicy man page, I was optimistically expecting that= excess > stale pwdFailureTime values might be removed from the entry after pwdMa= xFailure > was exceeded. For example, if pwdMaxFailure is 5, then only the most re= cent 5 > pwdFailureTime values would be kept, and the old ones purged as and whe= n new > failed bind attempts were made. >=20 > This wording in the slapo-ppolicy man page sounds friendly towards this= > interpretation: "Excess timestamps beyond those allowed by pwdMaxFailur= e may > also be purged." >=20 > Looking at the source code though, it doesn't seem that pwdFailureTime = values > are actually removed unless a successful bind occurs -- whereupon all v= alues of > course are removed. >=20 > I would like to request an enhancement to purge stale pwdFailureTime va= lues as > mentioned above. Nope. The number of pwdFailureTime is also used as failure lockout counte= r. Actually it was improved with ITS#7161. > This would also largely mitigate the issue raised in ITS#7089 I don't see the relation with ITS#7089. Ciao, Michael. --------------ms040304010104090205010307 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwMjIyMDgzOVowLwYJKoZIhvcNAQkEMSIE IP4/I+JcpHl9IrtvlMxjsSSZ5vx8RYJPw0b0IO3WK0k5MGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQAqQgw0y1hXKHQV5pBgxYa1fHdEaxKhKBUEI6fuKoLyPHtSi1ogTl3f pDOyssMJ6yCrpIraHLQhYkFt2YKooARQbUGwi2hhUm64DZiG2h5ZCv8wGWbE/KDVVCU1hMF7 LMPKyIxbLBFRA9rJUx5ElY8QbkVdYja15MyIg/dJEIgExhrA9XllBVfdNgyAwv/NXTOK3+tm YFdJLnGtiDhiNMsA2Zqji5g26MbeUyhCpl91eOI6hbrHKdXLW+GJiLyexo41fIqAqhNlYZyP s8TRkcyKUSm6FjMfGdpjIeppfDiAEogt1KSRZ/MC+Jtl9weSIdK8nJzaJlHHgedoVajqMEcF AAAAAAAA --------------ms040304010104090205010307--

1 0

(ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 02 Jul '15

02 Jul '15

Full_Name: Kartik Subbarao Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.75.228.155) Reading the slapo-ppolicy man page, I was optimistically expecting that excess stale pwdFailureTime values might be removed from the entry after pwdMaxFailure was exceeded. For example, if pwdMaxFailure is 5, then only the most recent 5 pwdFailureTime values would be kept, and the old ones purged as and when new failed bind attempts were made. This wording in the slapo-ppolicy man page sounds friendly towards this interpretation: "Excess timestamps beyond those allowed by pwdMaxFailure may also be purged." Looking at the source code though, it doesn't seem that pwdFailureTime values are actually removed unless a successful bind occurs -- whereupon all values of course are removed. I would like to request an enhancement to purge stale pwdFailureTime values as mentioned above. This would also largely mitigate the issue raised in ITS#7089 without needing to develop more involved code for that. The common theme is to ensure that pwdFailureTime values can't keep accumulating without bound, due to broken/misconfigured clients that are beyond the LDAP server administrator's control.

1 0

(ITS#8184) MOD operation with a double delete of a pwdFailureTime attribute
by elecharny＠apache.org 02 Jul '15

02 Jul '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: Submission from: (NULL) (212.195.127.200) We get an error when trying to change a password in some combinaison of settings : - 2 servers, one being the master, one being the slave - a few backends (MDB) - one of those backends using the glue overlay, the other being subordinates - 2 backends using the PPolicy overlay : the one which is the parent, and another one being a subordinate. FTR, the PPolicy in use are different What happens is that the password update will try to delete the pwdFailureTime attribute of the impacted entry (and two other attributes, too : pwdGraceUseTime and pwdAccountLockedTime. As we have 2 PPolicies, the attribute deletion will be requested twice, in one single MOD operation. The second DEL modification will then fail, leading to the rejection of the modification. To make it a bit more complex, the pwdFailureTime was updated on the slave, not replicated (it's a slave), and the password update was done on the master, so the failure was on the slave, as the master was pushing the modification to it. At the end, the two servers were not anymore in sync. The reason for this failure was that the code in charge of checking the MOD request, in ppolicy.c, lines 1575 to 1666, aren't checking if a DEL of one of the three attributes is already present in the list of MODIFICATION. Howard's suggestion to get this fix is to replace this code : got_del_fail = 1; if ( !a_fail ) drop = 1; by : if ( !a_fail || got_del_fail ) { drop = 1; } else { got_del_fail = 1; }

1 0

(ITS#8183) ldap_init() failed at sub thread but runs ok at main.
by 1727647302＠qq.com 02 Jul '15

02 Jul '15

Full_Name: wondersoft Version: 2.4.39 OS: CentOS 6.6 X86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (182.50.119.36) Hi: My server is CentOS 6.6(x86_64). When I create a thread on the main(), it's failed on ldap_init(), but it's ok at main not running on a sub thread. But using the same version and the same code, it runs pretty well at CentOS 6.6(x86_32). Test code is here: void pthread_ldap() { LDAP *ld = NULL; ld=(LDAP*)ldap_init(HOSTNAME,0); if(ld ==NULL) { perror("ldap_init"); return ; } int protocolVersion = LDAP_VERSION3; //It failed here, if ituns s on CentOS 6.6(x86_64) as a sub thread. ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &(protocolVersion)); return ; } int main() { int ret = 0; pthread_attr_t attr_attribute; pthread_attr_init(&attr_attribute); pthread_attr_setdetachstate(&attr_attribute,PTHREAD_CREATE_DETACHED); pthread_t pid; //If no sub thread created, it's ok //pthread_ldap(); if( pthread_create( &pid, &attr_attribute, (void*)pthread_ldap, NULL ) ) { perror(" Create pthread_ldap ERROR"); } } gdb chasing result: (gdb) 222 rc = ldap_set_option(ld, LDAP_OPT_HOST_NAME, defhost); (gdb) 223 if ( rc != LDAP_SUCCESS ) { (gdb) p ld $6 = (LDAP *) 0x7ffff00008c0 (gdb) pthread_ldap () at OPENLDAP_exam.c8686 186 printf("ldap_init ld = %d\n", ld); (gdb) p ld $7 = (LDAP *) 0xfffffffff00008c0 gcc version: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. OS version: Linux localhost.localdomain 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux gcc command: gcc OPENLDAP_exam.c -g -o OPENLDAP_exam -L/usr/local/lib -lldap -llber -lpthread

1 0

(ITS#8182) setspec matching fails unexpectedly
by daniel.kauffman＠rocksolidsolutions.org 01 Jul '15

01 Jul '15

Full_Name: Daniel Kauffman Version: 2.4.40 OS: Debian 8.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.178.89.137) Issue: Using access control set=<setspec> to compare an attribute value against a string converts the attribute value to lower case but does not convert the string to lower case, so matching sometimes fails unexpectedly. Expected behavior: When an attribute value is compared against a string, matching should use the attribute equality matching rule to determine whether or not to do a case-sensitive match. An exact match would not convert either the attribute value or the string, and a case-insensitive matching rule would convert both the attribute value and the string for comparison. Steps to reproduce: Create a user objectclass with a roleName attribute and set the attribute value to "canBrowse". Note the mixed case. Create an access control statement with mixed case: olcAccess: to * by set="user/roleName & [canBrowse]" read Because the roleName attribute value is converted to lower-case before comparison, the above will always fail, regardless of the case of the roleName attribute value. However, this works, regardless of the case of the roleName attribute value: olcAccess: to * by set="user/roleName & [canbrowse]" read

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 30 Jun '15

30 Jun '15

This is a multi-part message in MIME format. --------------090704060507030702010600 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >=20 >>> Can I raise the debug level? Log level trace does not really show the= ori=3D >>> ginal >>> byte sequence received by the external listener. >> >> Currently there is no debug code for this. >=20 > Actually, if you use debug level SHELL you'll get a plaintext dump of t= he=20 > received text. If you direct this into a file you can examine it with a= hex=20 > editor. I tested this again running as overlay with -d SHELL. See attachment of t= he log excerpt as Python string representation read with open(file,'rb') bef= ore. You can find *exactly* the lines from this response string generated by t= he external listener: 'RESULT\nmsgid: 1\ncode: 49\ninfo: HOTP value wrong\n\n' All lines starting with sock search reading line: (RESULT\n) (msgid: 1\n) (code: 49\n) (info: HOTP value wrong\n) Excerpt of slapd's log repeated here for better readability in the ITS. P= lease note the extra space after "text=3D" which is not what the external liste= ner returned. ------------------------------------------------ 5592d039 sock search reading line (RESULT ) 5592d039 sock search reading line (msgid: 1 ) 5592d039 sock search reading line (code: 49 ) 5592d039 sock search reading line (info: HOTP value wrong ) 5592d039 sock search reading line ( ) 5592d039 str2result (msgid: 1 code: 49 info: HOTP value wrong ) unknown 5592d039 str2result ( ) unknown 5592d039 conn=3D1000 op=3D0 RESULT tag=3D97 err=3D49 text=3D HOTP value w= rong ------------------------------------------------ Ciao, Michael. --------------090704060507030702010600 Content-Type: text/plain; charset=UTF-8; name="string" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="string" NTU5MmQwMzkgY29ubj0xMDAwIGZkPTEyIEFDQ0VQVCBmcm9tIFBBVEg9L29wdC91aS92YXIv b3BlbmxkYXAvcnVuL2xkYXBpLXAgKFBBVEg9L29wdC91aS92YXIvb3BlbmxkYXAvcnVuL2xk YXBpLXApXG41NTkyZDAzOSBjb25uPTEwMDAgb3A9MCBCSU5EIGRuPSJ1aWQ9c2VvZmosY249 dGVzdCxvdT1leGFtcGxlIiBtZXRob2Q9MTI4XG41NTkyZDAzOSBjb25uPTEwMDEgZmQ9MTQg QUNDRVBUIGZyb20gUEFUSD0vb3B0L3VpL3Zhci9vcGVubGRhcC9ydW4vbGRhcGktcCAoUEFU SD0vb3B0L3VpL3Zhci9vcGVubGRhcC9ydW4vbGRhcGktcClcbjU1OTJkMDM5IGNvbm49MTAw MSBvcD0wIEJJTkQgZG49IiIgbWV0aG9kPTE2M1xuNTU5MmQwMzkgY29ubj0xMDAxIG9wPTAg QklORCBhdXRoY2lkPSJnaWROdW1iZXI9MTAwK3VpZE51bWJlcj0xMDAwLGNuPXBlZXJjcmVk LGNuPWV4dGVybmFsLGNuPWF1dGgiIGF1dGh6aWQ9ImdpZE51bWJlcj0xMDArdWlkTnVtYmVy PTEwMDAsY249cGVlcmNyZWQsY249ZXh0ZXJuYWwsY249YXV0aCJcbjU1OTJkMDM5IGNvbm49 MTAwMSBvcD0wIEJJTkQgZG49ImNuPXJvb3Qsb3U9ZXhhbXBsZSIgbWVjaD1FWFRFUk5BTCBz YXNsX3NzZj0wIHNzZj0yNTZcbjU1OTJkMDM5IGNvbm49MTAwMSBvcD0wIFJFU1VMVCB0YWc9 OTcgZXJyPTAgdGV4dD1cbjU1OTJkMDM5IGNvbm49MTAwMSBvcD0xIFNSQ0ggYmFzZT0idWlk PXNlb2ZqLGNuPXRlc3Qsb3U9ZXhhbXBsZSIgc2NvcGU9MCBkZXJlZj0wIGZpbHRlcj0iKCYo b2JqZWN0Q2xhc3M9b2F0aEhPVFBVc2VyKShvYXRoSE9UUENvdW50ZXI9Kikob2F0aFNlY3Jl dD0qKSh8KCEodWlOb3RCZWZvcmU9KikpKHVpTm90QmVmb3JlPD0yMDE1MDYzMDE3MjIwMVop KSh8KCEodWlOb3RBZnRlcj0qKSkodWlOb3RBZnRlcj49MjAxNTA2MzAxNzIyMDFaKSkpIlxu NTU5MmQwMzkgY29ubj0xMDAxIG9wPTEgU1JDSCBhdHRyPW9hdGhIT1RQQ291bnRlciBvYXRo SE9UUFBhcmFtcyBvYXRoU2VjcmV0IG9hdGhUb2tlblNlcmlhbE51bWJlciBvYmplY3RDbGFz cyBwd2RQb2xpY3lTdWJlbnRyeSB1c2VyUGFzc3dvcmRcbjU1OTJkMDM5IGNvbm49MTAwMSBv cD0xIFNFQVJDSCBSRVNVTFQgdGFnPTEwMSBlcnI9MCBuZW50cmllcz0xIHRleHQ9XG41NTky ZDAzOSBjb25uPTEwMDEgb3A9MiBTUkNIIGJhc2U9ImNuPW9hdGgtcG9saWN5LWhvdHAtdXNl cnMsY249ZXhhbXBsZSxvdT1leGFtcGxlIiBzY29wZT0wIGRlcmVmPTAgZmlsdGVyPSIob2Jq ZWN0Q2xhc3M9b2F0aEhPVFBQYXJhbXMpIlxuNTU5MmQwMzkgY29ubj0xMDAxIG9wPTIgU1JD SCBhdHRyPW9hdGhIT1RQQ291bnRlck1heCBvYXRoSE9UUExvb2tBaGVhZCBvYXRoT1RQTGVu Z3RoXG41NTkyZDAzOSBjb25uPTEwMDEgb3A9MiBTRUFSQ0ggUkVTVUxUIHRhZz0xMDEgZXJy PTAgbmVudHJpZXM9MSB0ZXh0PVxuNTU5MmQwMzkgc29jayBzZWFyY2ggcmVhZGluZyBsaW5l IChSRVNVTFRcbilcbjU1OTJkMDM5IHNvY2sgc2VhcmNoIHJlYWRpbmcgbGluZSAobXNnaWQ6 IDFcbilcbjU1OTJkMDM5IHNvY2sgc2VhcmNoIHJlYWRpbmcgbGluZSAoY29kZTogNDlcbilc bjU1OTJkMDM5IHNvY2sgc2VhcmNoIHJlYWRpbmcgbGluZSAoaW5mbzogSE9UUCB2YWx1ZSB3 cm9uZ1xuKVxuNTU5MmQwMzkgc29jayBzZWFyY2ggcmVhZGluZyBsaW5lIChcbilcbjU1OTJk MDM5IHN0cjJyZXN1bHQgKG1zZ2lkOiAxXG5jb2RlOiA0OVxuaW5mbzogSE9UUCB2YWx1ZSB3 cm9uZ1xuXG4pIHVua25vd25cbjU1OTJkMDM5IHN0cjJyZXN1bHQgKFxuKSB1bmtub3duXG41 NTkyZDAzOSBjb25uPTEwMDAgb3A9MCBSRVNVTFQgdGFnPTk3IGVycj00OSB0ZXh0PSBIT1RQ IHZhbHVlIHdyb25nXG41NTkyZDAzOSBjb25uPTEwMDAgb3A9MSBVTkJJTkRcbjU1OTJkMDM5 IGNvbm49MTAwMCBmZD0xMiBjbG9zZWRcbg== --------------090704060507030702010600--

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by h.b.furuseth＠usit.uio.no 30 Jun '15

30 Jun '15

On 30. juni 2015 14:52, hyc(a)symas.com wrote: > We have already documented this. "Database names are kept as keys in the > unnamed database." "Hey, that may mean I can drop a DB without having to open it and mess with LMDB's DBI handling! Let me try this..." > It should be obvious that if you muck with the record of an > existing key, things will change, therefore you should not muck with those keys. Lots of people think differently than you or me. We're not going to agree. Not on this, and not on what you said in your next mail. I don't see the point of rehashing those arguments yet again, and I didn't intend to. I was just ITSing a commit before pushing, _after_ asking you about it. I thought. -- Hallvard

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 30 Jun '15

30 Jun '15

Hallvard Breien Furuseth wrote: > On 29/06/15 23:05, hyc(a)symas.com wrote: >> Seriously, why aren't we just saying "don't do this" and moving on? > > OK, then document it. Maybe keeping it simple, call > mixing mainDB data and named DBs a user error and warn this > can break the DB. > >> There are >> lots of stupid things you can do with software. It's a waste of time and >> energy to prevent them all. > > We totally disagree, starting with what is stupid. But we knew > that. Ultimately it's redundant work. I.e., every restriction you place inside the code still requires documentation, otherwise all you've done is changed "why doesn't this work" into "why doesn't LMDB let me do what I tried to do?" Simpler to only write the doc and leave the code pristine. The library's purpose is to perform its intended uses efficiently. Misuses are not our responsibility. Preventing misuse is the responsibility of the documentation, it doesn't belong in the code. -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 30 Jun '15

30 Jun '15

Hallvard Breien Furuseth wrote: > On 29/06/15 23:05, hyc(a)symas.com wrote: >> Seriously, why aren't we just saying "don't do this" and moving on? > > OK, then document it. Maybe keeping it simple, call > mixing mainDB data and named DBs a user error and warn this > can break the DB. We have already documented this. "Database names are kept as keys in the unnamed database." It should be obvious that if you muck with the record of an existing key, things will change, therefore you should not muck with those keys. >> There are >> lots of stupid things you can do with software. It's a waste of time and >> energy to prevent them all. > > We totally disagree, starting with what is stupid. But we knew > that. That's I asked which parts of "mdb/bundle" to push and > which you rejected, we must have misunderstood each other. I > thought I was just ITSing this commit properly before pushing. I just don't see this happening in practice. Most applications will never use subDBs. It's not like some random person is going to come along and open an arbitrary LMDB file created by some other application and start mucking with it, without knowing the meaning of what's inside. Embedded database libraries are used in specific contexts by their enclosing application. They don't just get random ops thrown at them from 3rd party code. The designer of the enclosing app will design a schema/whatever set of tables to use and that scheme will be fixed for the life of the application. -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by h.b.furuseth＠usit.uio.no 30 Jun '15

30 Jun '15

On 29/06/15 23:05, hyc(a)symas.com wrote: > Seriously, why aren't we just saying "don't do this" and moving on? OK, then document it. Maybe keeping it simple, call mixing mainDB data and named DBs a user error and warn this can break the DB. > There are > lots of stupid things you can do with software. It's a waste of time and > energy to prevent them all. We totally disagree, starting with what is stupid. But we knew that. That's I asked which parts of "mdb/bundle" to push and which you rejected, we must have misunderstood each other. I thought I was just ITSing this commit properly before pushing.

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by hyc＠symas.com 30 Jun '15

30 Jun '15

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Can I raise the debug level? Log level trace does not really show the ori= >> ginal >> byte sequence received by the external listener. > > Currently there is no debug code for this. Actually, if you use debug level SHELL you'll get a plaintext dump of the received text. If you direct this into a file you can examine it with a hex editor. -- -- 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#8048) back-sock/slapo-sock issue
by hyc＠symas.com 30 Jun '15

30 Jun '15

michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> michael(a)stroeder.com wrote: >>>> Null-bytes really needed? >>> >>> Hmm, with null-bytes the wrong result code is returned to the LDAP cli= > ent. >>> >>> Without null-bytes the correct result code is returned to the client b= > ut slapd >>> complains about unknown string: >>> >>> 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=3Dwuqww,cn=3Dampua,ou=3Dampu= > a\ninfo: >>> NOK\n\n' >>> >>> results in log message: >>> >>> 559174df str2result (msgid: 1 >>> code: 0 >>> >>> ) unknown >>> 559174df str2result ( >>> ) unknown >> =20 >> I would almost suspect you were running on Windows. None of the behavio= > r >> you're reporting occurs for me using the searchexample.pl script. > > Your script does not return any real 'RESULT..' responses. Sure it does: print "dn: cn=test, dc=example, dc=com\n"; print "cn: test\n"; print "objectclass: cnobject\n"; print "\n"; print "RESULT\n"; print "code: 0\n"; print "info: answered by process $$\n"; And the result at the client: violino:~/OD/hobj/tests> ../clients/tools/ldapsearch -x -H ldap://:9011 -b dc=example,dc=com # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # test, example.com dn: cn=test,dc=example,dc=com cn: test objectClass: cnobject # search result search: 2 result: 0 Success text: answered by process 3077 # numResponses: 2 # numEntries: 1 Notice there are no embedded NUL characters. Only newlines. > I also have less issues when just returning 'CONTINUE\n'. > >> Sounds like your problem is a python runtime configuration, not a slapd= > >> bug. > > Not on Windows and no run-time configuration involved. > > Look at the raw string representations I've posted. That string goes dire= > ctly > to SocketServer.BaseRequestHandler.request.sendall(response_str). > > Can I raise the debug level? Log level trace does not really show the ori= > ginal > byte sequence received by the external listener. Currently there is no debug code for this. At any rate, the code uses fgets(3) which stops reading at a newline character. The fact that your string isn't being parsed correctly implies either libc fgets is broken inside your slapd process (pretty unlikely) or your socket sender isn't really sending newline characters. -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 29 Jun '15

29 Jun '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB_0.9.15 > OS: > URL: > Submission from: (NULL) (81.191.45.5) > Submitted by: hallvard > > > The user can overwrite or delete a named DB record > with normal data. This leaks the pages of the DB. > Also the new non-DB can then be treated as a DB. > A fix is coming (from my branch mdb/bundle). Seriously, why aren't we just saying "don't do this" and moving on? There are lots of stupid things you can do with software. It's a waste of time and energy to prevent them all. -- -- 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#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Howard Chu wrote: > michael(a)stroeder.com wrote: >> michael(a)stroeder.com wrote: >>> Null-bytes really needed? >> >> Hmm, with null-bytes the wrong result code is returned to the LDAP cli= ent. >> >> Without null-bytes the correct result code is returned to the client b= ut slapd >> complains about unknown string: >> >> 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=3Dwuqww,cn=3Dampua,ou=3Dampu= a\ninfo: >> NOK\n\n' >> >> results in log message: >> >> 559174df str2result (msgid: 1 >> code: 0 >> >> ) unknown >> 559174df str2result ( >> ) unknown >=20 > I would almost suspect you were running on Windows. None of the behavio= r > you're reporting occurs for me using the searchexample.pl script. Your script does not return any real 'RESULT..' responses. I also have less issues when just returning 'CONTINUE\n'. > Sounds like your problem is a python runtime configuration, not a slapd= > bug. Not on Windows and no run-time configuration involved. Look at the raw string representations I've posted. That string goes dire= ctly to SocketServer.BaseRequestHandler.request.sendall(response_str). Can I raise the debug level? Log level trace does not really show the ori= ginal byte sequence received by the external listener. Ciao, Michael.

1 0

(ITS#8181) LMDB page leaks etc when treating DBs as data
by h.b.furuseth＠usit.uio.no 29 Jun '15

29 Jun '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard The user can overwrite or delete a named DB record with normal data. This leaks the pages of the DB. Also the new non-DB can then be treated as a DB. A fix is coming (from my branch mdb/bundle).

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by hyc＠symas.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Null-bytes really needed? > > Hmm, with null-bytes the wrong result code is returned to the LDAP client. > > Without null-bytes the correct result code is returned to the client but slapd > complains about unknown string: > > 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' > > results in log message: > > 559174df str2result (msgid: 1 > code: 0 > > ) unknown > 559174df str2result ( > ) unknown I would almost suspect you were running on Windows. None of the behavior you're reporting occurs for me using the searchexample.pl script. Sounds like your problem is a python runtime configuration, not a slapd bug. -- -- 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#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

michael(a)stroeder.com wrote: > Null-bytes really needed? Hmm, with null-bytes the wrong result code is returned to the LDAP client. Without null-bytes the correct result code is returned to the client but slapd complains about unknown string: 'RESULT\nmsgid: 1\ncode: 49\nmatched: uid=wuqww,cn=ampua,ou=ampua\ninfo: NOK\n\n' results in log message: 559174df str2result (msgid: 1 code: 0 ) unknown 559174df str2result ( ) unknown

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Michael Str=F6der wrote: > This is my Python response string: >=20 > 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' Hmmpf! After adding null-bytes in each line like this 'RESULT\n\x00msgid: 1\n\x00code: 49\n\x00\n\x00' at least this message went away also with RE24: > This leads to slapd debug output: >=20 > 55914b01 str2result (msgid: 1 > code: 49 > info: remote NOK >=20 > ) unknown > 55914b01 str2result ( > ) unknown Null-bytes really needed? str2result() checks for null-bytes in a bunch o= f cases. I really wonder why null-terminated char *s is used. Ciao, Michael.

1 0

Re: (ITS#8048) back-sock/slapo-sock issue
by michael＠stroeder.com 29 Jun '15

29 Jun '15

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: 2.4 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (110.49.207.42) > Submitted by: hyc >=20 > The result parser is checking for CONTINUE in the wrong place. Please re-open this ticket. RE24 (tagged as 2.4.41) made things worse. Is there a chance to get things fixed? I promise to help testing. First CONTINUE\n works in RE24 better than in 2.4.40 which was the cause = of this ITS. But handling RESULT is seriously broken, even more than in 2.4.40. Example: This is my Python response string: 'RESULT\nmsgid: 1\ncode: 49\ninfo: remote NOK\n\n' This leads to slapd debug output: 55914b01 str2result (msgid: 1 code: 49 info: remote NOK ) unknown 55914b01 str2result ( ) unknown Note that the whole string is returned as being unknown. Also with 2.4.40 my client script receives ' remote NOK' as diagnostic message. With RE24 the diagnostic message is complete garbage. So I tried many response string variants regarding number of \n and leavi= ng away space after the colon etc. But not really working. Sometimes slapd hangs, sometimes my client hangs e.g. when sending two subsequent bind requests in one open LDAP connection.

1 0

(ITS#8180) back-sock should not return sucess in case of error
by michael＠stroeder.com 29 Jun '15

29 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (84.181.173.53) back-sock should definitely never return success(0) to the client in case the external listener returned non-parseable message: Example trace log: 55913915 => str2entry: "FOOBAR msgid: 1 code: 49 " 55913915 <= str2entry NULL (parse_line) 55913915 str2entry: entry -1 has no dn 55913915 str2entry(FOOBAR) failed 55913915 sock: fgets failed: Success (0)

1 0

(ITS#8179) LMDB: Feature Request: mdb_env_check_mapsize(env)
by scott＠GameRanger.com 28 Jun '15

28 Jun '15

Full_Name: Scott Kevill Version: LMDB 0.9.14 OS: CentOS 5-7 URL: ftp://ftp.openldap.org/incoming/scott-kevill-150628.patch Submission from: (NULL) (60.224.160.178) mdb_txn_begin / mdb_txn_renew will return MDB_MAP_RESIZED for the current process if another process has changed the mapsize AND the data has grown past the current process mapsize. However, by that point, in a multithreaded environment it may be difficult to wind back to a "safe" point of no active txns in order to call mdb_env_set_mapsize(env, 0) to update the mapsize. Requesting: int mdb_env_check_mapsize(MDB_env *env); to return either MDB_SUCCESS or MDB_MAP_RESIZED. This should be lightweight enough to call frequently enough to decide whether to initiate a "safe" point to enable calling mdb_env_set_mapsize(env, 0). Return MDB_SUCCESS if the MDB has not been opened yet. Scenario: - Process W is a writer - Process R is a reader with multiple reader threads (read-only) - Both processes are running and using a 2GB mapsize MDB - Data is currently 1GB - Ops decide W should increase mapsize to 3GB allowing for more expansion - W calls mdb_env_set_mapsize(env, 3GB) - R's mapsize remains at 2GB%0 D Data grows - R:1 thread begins a moderately long read-only txn - Data grows past 2GB - R:2 thread tries to begin a read-only txn, but fails with MDB_MAP_RESIZED - R:2 thread cannot call mdb_env_set_mapsize(env, 0), because of R:1's txn - A major control flow issue exists now, as R:2 may be deep into work, but can't continue nor back out With mdb_env_check_mapsize(), R could periodically test it and if needed, initiate a "safe" point where none of R's threads have active txns. This could be done long before the data size actually reaches R's original mapsize (ie. when data is ~1GB rather >2GB). - Enforcing synchronisation to a "safe" point might be relatively expensive, so it would be important to know if the mapsize has changed first. ie. Making mdb_env_set_mapsize(env, 0) lightweight for the unchanged mapsize case isn't enough I've attached a sample patch against master (scott-kevill-150628.patch). I've tested it against 0.9.14. The code is trivial and is based on the behaviour of mdb_env_set_mapsize(env, 0). I didn't use git for the patch, so not too difficult to get working. Less than 10 new lines, but for the record, I release it to public domain. Feel free to massage it as needed.

1 0

Re: (ITS#7791) 3-Way delta MMR segfault
by quanah＠zimbra.com 27 Jun '15

27 Jun '15

--On Saturday, June 27, 2015 8:01 AM +0000 frederic.nass(a)univ-lorraine.fr wrote: > ------=_Part_4076294_1166621201.1435388481648 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: quoted-printable > > Hi,=20 > > We are facing the exact same situation with a 3-way configuration with > open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20 > > Slapd crashes at some point during first replication. We can reproduce > this= on any of the 3 nodes by stopping ldap service, deleting databases > (access= log and mdb) and restarting ldap service.=20 > > Please tell us how we can be helpful.=20 Provide a gdb backtrace. <http://www.openldap.org/faq/data/cache/59.html> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7791) 3-Way delta MMR segfault
by frederic.nass＠univ-lorraine.fr 27 Jun '15

27 Jun '15

------=_Part_4076294_1166621201.1435388481648 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=20 We are facing the exact same situation with a 3-way configuration with open= ldap-2.4.39.2z packaged by Zimbra 8.6 p2.=20 Slapd crashes at some point during first replication. We can reproduce this= on any of the 3 nodes by stopping ldap service, deleting databases (access= log and mdb) and restarting ldap service.=20 Please tell us how we can be helpful.=20 Fr=C3=A9d=C3=A9ric Nass=20 Sous-direction Infrastructures=20 Direction du Num=C3=A9rique=20 Universit=C3=A9 de Lorraine=20 ------=_Part_4076294_1166621201.1435388481648 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Hi,</div><div> </di= v><div>We are facing the exact same situation with a 3-way configurati= on with openldap-2.4.39.2z packaged by Zimbra 8.6 p2.</div><div> </= div><div>Slapd crashes at some point during first replication. We can repro= duce this on any of the 3 nodes by stopping ldap service, deleting dat= abases (accesslog and mdb) and restarting ldap service.</div><div> </div= ><div>Please tell us how we can be helpful.</div><div data-marker=3D"__SIG_= PRE__"> Fr=C3=A9d=C3=A9ric Nass Sous-direction Infrastructures <b= r>Direction du Num=C3=A9rique Universit=C3=A9 de Lorraine </div></d= iv></body></html> ------=_Part_4076294_1166621201.1435388481648--

1 0

Re: (ITS#8173)
by hyc＠symas.com 25 Jun '15

25 Jun '15

Adrian.Raemy(a)vtg.admin.ch wrote: > --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Dear Howard, > > I did a core dump when the crash occurred at slapd respectively when the ba= > ck-ldap crashed. > Maybe the output of the gdb can help you find out where the problem is. > Please let me know what you need more. This trace seems to lack debug symbols. Without source line numbers etc. there's nothing we can determine from this trace. Please read the FAQ. http://www.openldap.org/faq/index.cgi?file=59 The trace shows that you probably have some overlays configured. What overlays? You need to provide your slapd config files if you want any help here. Volunteers aren't going to go out of their way to help you if you aren't going to provide the needed info. > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fc0627492c6 in ldap_back_bind () > (gdb) where > #0 0x00007fc0627492c6 in ldap_back_bind () > #1 0x00007fc062639fcb in fe_op_bind () > #2 0x00007fc0626a86fd in overlay_op_walk () > #3 0x00007fc0626a8956 in over_op_func () > #4 0x00007fc0626a89de in over_op_bind () > #5 0x00007fc062639697 in do_bind () > #6 0x00007fc06260ff19 in connection_operation () > #7 0x00007fc0626104e1 in connection_read_thread () > #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= > ibldap_r-2.4.so.2 > #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 > #10 0x00007fc05fda902d in clone () from /lib64/libc.so.6 > #11 0x0000000000000000 in ?? () > > Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= > s://0.0.0.0:636 -f /etc/op'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007fc0627492c6 in ldap_back_bind () > (gdb) where > #0 0x00007fc0627492c6 in ldap_back_bind () > #1 0x00007fc062639fcb in fe_op_bind () > #2 0x00007fc0626a86fd in overlay_op_walk () > #3 0x00007fc0626a8956 in ?? () > #4 0x00007fc0626a89de in ?? () > #5 0x00007fc062639697 in do_bind () > #6 0x00007fc06260ff19 in ?? () > #7 0x00007fc0626104e1 in ?? () > #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= > ibldap_r-2.4.so.2 > #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 > #10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6 > #11 0x0000000000000000 in ?? () > > Best regards > Adrian -- -- 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#8173)
by Adrian.Raemy＠vtg.admin.ch 24 Jun '15

24 Jun '15

--_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Howard, I did a core dump when the crash occurred at slapd respectively when the ba= ck-ldap crashed. Maybe the output of the gdb can help you find out where the problem is. Please let me know what you need more. Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc0627492c6 in ldap_back_bind () (gdb) where #0 0x00007fc0627492c6 in ldap_back_bind () #1 0x00007fc062639fcb in fe_op_bind () #2 0x00007fc0626a86fd in overlay_op_walk () #3 0x00007fc0626a8956 in over_op_func () #4 0x00007fc0626a89de in over_op_bind () #5 0x00007fc062639697 in do_bind () #6 0x00007fc06260ff19 in connection_operation () #7 0x00007fc0626104e1 in connection_read_thread () #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 #10 0x00007fc05fda902d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Core was generated by `/usr/lib/openldap/slapd -h ldap://0.0.0.0:389 ldap= s://0.0.0.0:636 -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc0627492c6 in ldap_back_bind () (gdb) where #0 0x00007fc0627492c6 in ldap_back_bind () #1 0x00007fc062639fcb in fe_op_bind () #2 0x00007fc0626a86fd in overlay_op_walk () #3 0x00007fc0626a8956 in ?? () #4 0x00007fc0626a89de in ?? () #5 0x00007fc062639697 in do_bind () #6 0x00007fc06260ff19 in ?? () #7 0x00007fc0626104e1 in ?? () #8 0x00007fc062145c3c in ldap_int_thread_pool_wrapper () from /usr/lib64/l= ibldap_r-2.4.so.2 #9 0x00007fc06155e806 in start_thread () from /lib64/libpthread.so.0 #10 0x00007fc05fda902d in gnu_dev_makedev () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Best regards Adrian --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE-CH" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Dear Howard,<o:p></o:p> <o:p> </o:p> I did a core dump when the cras= h occurred at slapd respectively when the back-ldap crashed.<o:p></o:p></sp= an> Maybe the output of the gdb can= help you find out where the problem is.<o:p></o:p> Please let me know what you nee= d more.<o:p></o:p> <o:p> </o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fc062639fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fc0626a86fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fc0626a8956 in = over_op_func ()<o:p></o:p> #4  0x00007fc0626a89de in = over_op_bind ()<o:p></o:p> #5  0x00007fc062639697 in = do_bind ()<o:p></o:p> #6  0x00007fc06260ff19 in = connection_operation ()<o:p></o:p> #7  0x00007fc0626104e1 in = connection_read_thread ()<o:p></o:p> #8  0x00007fc062145c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fc06155e806 in = start_thread () from /lib64/libpthread.so.0<o:p></o:p> #10 0x00007fc05fda902d in clone= () from /lib64/libc.so.6<o:p></o:p> #11 0x0000000000000000 in ?? ()= <o:p></o:p> <o:p> </o:p> Core was generated by `/usr/lib= /openldap/slapd -h  ldap://0.0.0.0:389  ldaps://0.0.0.0:636 = -f /etc/op'.<o:p></o:p> Program terminated with signal = 11, Segmentation fault.<o:p></o:p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> (gdb) where<o:p></o:p></= p> #0  0x00007fc0627492c6 in = ldap_back_bind ()<o:p></o:p> #1  0x00007fc062639fcb in fe_op_bind ()<o:p></o= :p> #2  0x00007fc0626a86fd in = overlay_op_walk ()<o:p></o:p> #3  0x00007fc0626a8956 in = ?? ()<o:p></o:p> #4  0x00007fc0626a89de in = ?? ()<o:p></o:p> #5  0x00007fc062639697 in = do_bind ()<o:p></o:p> #6  0x00007fc06260ff19 in = ?? ()<o:p></o:p> #7  0x00007fc0626104e1 in = ?? ()<o:p></o:p> #8  0x00007fc062145c3c in = ldap_int_thread_pool_wrapper () from /usr/lib64/libldap_r-2.4.so.2<o:p></o:= p> #9  0x00007fc06155e806 in = start_thread () from /lib64/libpthread.so.0<o:p></o:p> #10 0x00007fc05fda902d in gnu_d= ev_makedev () from /lib64/libc.so.6<o:p></o:p> #11 0x0000000000000000 in ?? ()= <o:p></o:p> <o:p>&nbs= p;</o:p> Best rega= rds<o:p></o:p> Adrian</s= pan><o:p></o:p> </div> </body> </html> --_000_BE8E19527611BA409D68FF6EA186AF9002A24849BEREXMBX19ifc1i_--

1 0

(ITS#8178) back-sock: Timeout to avoid locking
by michael＠stroeder.com 24 Jun '15

24 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (2001:8d8:1fe:700::1:3) If a back-sock listener does not correctly respond to a request slapd thread hangs forever and slapd has to be stopped with kill -9. slapd should implement a timeout after which it abandons processing the LDAP request.

1 0

(ITS#8177) RFE: back-sock to receive controls
by michael＠stroeder.com 22 Jun '15

22 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (84.178.24.72) It would be nice if back-sock would also receive the extended controls sent by the client and could generate response control to be returned to the client.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠gmail.com 22 Jun '15

22 Jun '15

Le 22/06/15 14:51, Howard Chu a écrit : > elecharny(a)gmail.com wrote: >> Ah, my bad then. >> >> What's the rational for having the RootDSE spread in many files though ? > > Probably different applications may add their own sets of attributes > as individual files. > Ok. Probably not a frequent use case, but never mind. The GUI shall not rule the server ! Thanks Mickaël, Howard for the clarifications.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by hyc＠symas.com 22 Jun '15

22 Jun '15

elecharny(a)gmail.com wrote: > Ah, my bad then. > > What's the rational for having the RootDSE spread in many files though ? Probably different applications may add their own sets of attributes as individual files. -- -- 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#8176) the olcRootDSE attributeType should be Single Value
by michael＠stroeder.com 22 Jun '15

22 Jun '15

elecharny(a)gmail.com wrote: > What's the rational for having the RootDSE spread in many files though ? If you have several packages which want to add something to the rootDSE you can spread this across several files. The same rationale like for /etc/cron.d, /etc/sudoers.d, ... Ciao, Michael.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠gmail.com 22 Jun '15

22 Jun '15

Ah, my bad then. What's the rational for having the RootDSE spread in many files though ?

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by hyc＠symas.com 22 Jun '15

22 Jun '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.195.127.200) > > > The olcRootDSE AttributeType is currently a Multiple Value AttributeType, which > is not necessary : it stores a file name which contains the RootDSE entry. It's > unlikely that we store more than one value in it, and the code currently reads > only one value anyway. Not true, the code will read multiple values. Multiple files' contents will be concatenated. -- -- 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#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠apache.org 22 Jun '15

22 Jun '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.195.127.200) The olcRootDSE AttributeType is currently a Multiple Value AttributeType, which is not necessary : it stores a file name which contains the RootDSE entry. It's unlikely that we store more than one value in it, and the code currently reads only one value anyway.

1 0

(ITS#8175) Some more missing parameter in the Configuration man page
by elecharny＠apache.org 19 Jun '15

19 Jun '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.195.127.200) The following options are not listed for the olcDisallows configuration parameter in the slapd-config man page : * proxy_authz_non_critical * dontusecopy_non_critical

1 0

Re: (ITS#8173) back-ldap slapd crash segfault
by hyc＠symas.com 18 Jun '15

18 Jun '15

adrian.raemy(a)vtg.admin.ch wrote: > Full_Name: Adrian Raemy > Version: 2.4.40 > OS: SLES 11 SP3 > URL: > Submission from: (NULL) (193.5.216.100) > > > Hi, > > The Openldap backend "ldap" slapd crashing under heavy load. > Tested with 2.4.26 and also 2.4.40. > We get an segfault: > Jun 18 00:00:36 serverxx1 kernel: [9079587.309374] slapd[6193]: segfault at 40 > ip 00007f184cf6b2c6 sp 00007f1838ff85c0 error 4 in slapd[7f184cdda000+26c000] > Jun 18 09:40:12 serverxx1 kernel: [9114294.985888] slapd[10309]: segfault at 40 > ip 00007f3b31f492c6 sp 00007f3b1f7f55c0 error 4 in slapd[7f3b31db8000+26c000] > Jun 18 12:38:29 serverxx1 kernel: [9124971.271300] slapd[15868]: segfault 4 40 > ip 00007fc1555512c6 sp 00007fc141ffa5c0 error 4 in slapd[7fc1553c0000+26c000] > We can't provide a core dump of the slapd due to confidentially restrictions. Then we cannot help you. I suggest you test with the 2.4.41 release candidate and see if the same crash still occurs. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs