Re: (ITS#8349) fix ppolicy issue
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms020403050300060907090405
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Frankly I don't understand your text.
hamano(a)osstech.co.jp wrote:
> We fixed several issue around ppolicy.
>=20
> 1) reduce pwdInHistory
> If set pwdInHistory to 5 then reduce pwdInHistory to 3,
I try to rephrase:
If attribute 'pwdHistory' in the user entry has 5 values and attribute
'pwdInHistory' in the policy entry is 3 then ignore (and remove?) the 2 o=
ldest
'pwdHistory' values.
Are values in 'pwdInHistory' sorted by timestamp in this part of the code=
?
> We expect to check password with three history, but ppolicy check
> password with all pwdHistory attribute.
>=20
> 2) reduce pwdInHistory to zero
> If set pwdInHistory to 5 then reduce pwdInHistory to 0,
I try to rephrase:
If attribute 'pwdHistory' in the user entry is set and attribute 'pwdInHi=
story'
in the policy entry is 0 then ignore (and remove?) 'pwdHistory' completel=
y.
> We expect that ppolicy password checking will be disbale. but the
> pwdHistory attribute are remains, so password checking is still
> enabled.
> We need to remove pwdHistory attribute.
I'm not sure whether removing 'pwdHistory' attribute (values) is the righ=
t thing
to do. If you want to increase 'pwdInHistory' later then the old values a=
re lost.
Ciao, Michael.
--------------ms020403050300060907090405
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
DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw
FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp
Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt
ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb
BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0
cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX
8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR
+yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp
9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0
AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu
9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU
ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG
CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v
cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB
dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg
dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t
IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g
Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w
LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB
BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j
bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j
ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j
Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E
vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el
8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i
nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT
jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp
dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp
bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi
p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f
tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW
oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/
43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB
rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc
4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG
AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G
CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw
UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw
Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB
AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN
BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb
WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4
OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0
KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0
4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0
IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6
fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt
jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4
8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI
XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB
ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t
IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD
BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2
MDExMjA4NDYyM1owLwYJKoZIhvcNAQkEMSIEILl7VIW7hBM9B4GYZ7Uyl+XMeUJC0AIM+vIl
mEhibpBVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg
Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm
aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy
bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAT4Ma6E7Ln+2anKcDh
prgMxupVAa0wcHggWiSTvY9Zmb9PNt/5/FSD7lJfCWB2kyEGhBoKidjMAUaLoGoyXpp6fVfH
iaKfW3cXIhv/bFJfkzxvrlqpygsHaQThytk/pU0c9AtyqDqv9emKZ6UlxvaCnX/367J1rW52
8wdluY8M95Ez67psCs59xrTtXrXZD7QIa+Y33xB53cMWR6kVcfT+d3NsFb0W6Yo1JPywekbs
F1TlK4Ro1ggE78C7Kx1ifxhVZxQmcg7sTbx8PEjJsSl6vYmTJpCtJofTcV5NF0+onn6XD3mj
xCNNyIzvQDTnFbcrJODyo0OX4pFj9Sjdmo7xAAAAAAAA
--------------ms020403050300060907090405--
7 years, 8 months
(ITS#8349) fix ppolicy issue
by hamano＠osstech.co.jp
Full_Name: HAMANO Tsukasa
Version: 2.4.43
OS: Linux
URL: https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHisto...
Submission from: (NULL) (240b:10:2640:bf0:290:4cff:fe0d:f43e)
We fixed several issue around ppolicy.
1) reduce pwdInHistory
If set pwdInHistory to 5 then reduce pwdInHistory to 3,
We expect to check password with three history, but ppolicy check
password with all pwdHistory attribute.
2) reduce pwdInHistory to zero
If set pwdInHistory to 5 then reduce pwdInHistory to 0,
We expect that ppolicy password checking will be disbale. but the
pwdHistory attribute are remains, so password checking is still
enabled.
We need to remove pwdHistory attribute.
Please apply the patch. Thank you.
7 years, 8 months
(ITS#8348) lmdb MDB_VL32 typeo in null check for txn0
by jeremiah.morrill＠econnect.tv
Full_Name: Jeremiah Morrill
Version: lmdb 0.9.70
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.120.130.199)
In the latest git repo, in mdb_env_close0, the null check on env->me_txn0 is
pointing to env->me_txn:
This:
#ifdef MDB_VL32
if (env->me_txn0 && env->me_txn->mt_rpages)
vs.
#ifdef MDB_VL32
if (env->me_txn0 && env->me_txn0->mt_rpages)
7 years, 8 months
(ITS#8347) lmdb VL32 sometimes not unmapping pages
by jeremiah.morrill＠econnect.tv
Full_Name: Jeremiah Morrill
Version: lmdb 0.9.70
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.120.130.199)
I changed the value of MDB_ERPAGE_SIZE to 256(16384/64) to try and tweak high
virtual-memory usage in 32bit. I believe this exposed a bug not hit in my
testing. Sometimes mmap'd sections(usually one or two) were not being munmapped
when the environment was closed. This was only evident after checking the
process with the Windows utility VMMap.
I observed that when this happened, in mdb_env_close0, the dangling mmap'd
sections were always at env->me_rpages[(MDB_ERPAGE_SIZE - 1) / 2], which in the
case of MDB_ERPAGE_SIZE of 256, would be at index 127.
This seemed like a possible off-by-one error. Below is a diff that seems to fix
the issue, but I do not stand by its correctness.
--- a/src/libraries/lmdb/mdb.c
+++ b/src/libraeses/lmdb/mdb.c
@@ -1404,7 +1404,7 @@ struct MDB_env {
#ifdef MDB_VL32
MDB_ID3L me_rpages; /**< like #mt_rpages, but global to env */
pthread_mutex_t me_rpmutex; /**< control access to #me_rpages */
-#define MDB_ERPAGE_SIZE 16384
+#define MDB_ERPAGE_SIZE (16384/64)
#define MDB_ERPAGE_MAX (MDB_ERPAGE_SIZE-1)
unsigned int me_rpcheck;
#endif
@@ -5851,7 +5851,7 @@ retry:
if (el[0].mid >= MDB_ERPAGE_MAX - env->me_rpcheck) {
/* purge unref'd pages */
unsigned i, y = 0;D%D
- for (i=1; i<el[0].mid; i++) {
+ for (i=1; i<=el[0].mid; i++) {
if (!el[i].mref) {
if (!y) y = i;
munmap(el[i].mptr, env->me_psize * el[i].mcnt);
7 years, 8 months
(ITS#8318)
by lkrispen＠redhat.com
Hi,
has there been an evaluation if this request would be accepted and
implemented ? When could it be available ?
Thanks,
Ludwig
7 years, 8 months
(ITS#8346) lmdb memory leak with MDB_VL32
by jeremiah.morrill＠econnect.tv
Full_Name: Jeremiah Morrill
Version: lmdb 0.9.70
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.120.130.199)
With MDB_VL32, I believe lmdb is leaking memory in env->txn0->mt_rpages.
Here is quick diff of what may fix this issue. Not sure if I have redundant
null checks.
diff --git a/src/libraries/lmdb/mdb.c b/src/libraries/lmdb/mdb.cAiAindex
11832ab..1f00a66 100644
--- a/src/libraries/lmdb/mdb.c
+++ b/src/libraries/lmdb/mdb.c
@@ -5255,14 +5255,20 @@ mdb_env_close0(MDB_env *env, int excl)
free(env->me_dbflags);
free(env->me_path);
free(env->me_dirty_list);
- free(env->me_txn0);
#ifdef MDB_VL32
+ if(env->me_txn0){
+ if(env->me_txn0->mt_rpages) {
+ free(env->me_txn0->mt_rpages);
+ }
+ }
{ unsigned int x;
for (x=1; x<=env->me_rpages[0].mid; x++)
munmap(env->me_rpages[x].mptr, env->me_rpages%5%5].mcnt * env->me_psize);
}
free(env->me_rpages);
#endif
+ free(env->me_txn0);
+
mdb_midl_free(env->me_free_pgs);
if (env->me_flags & MDB_ENV_TXKEY) {
7 years, 8 months
Re: (ITS#8340) test022-ppolicy failed
by dieter＠dkluenter.de
Hi,
I forgot to mention that the issue aroused after patching the code
with Nadezhda-Ivanova-151105.patch
-Dieter
--=20
Dieter Kl=C3=BCnter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53=C2=B037'09,95"N
10=C2=B008'02,42"E
7 years, 9 months
