(ITS#8582) LMDB lockfile/mutex arch dependency
by hyc＠openldap.org
Full_Name: Howard Chu
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.235.15.200)
Submitted by: hyc
I ran into some corruption problems when running a 64bit LMDB process concurrent
with a 32bit one using MDB_VL32. While LMDB's own structures are all 64bit clean
in a VL32 build, unfortunately pthread_mutex_t structures are not. In
particular, in glibc a pthread_mutex_t can be one of 3 different sizes - 24
bytes for 32bit runtime on 32bit processor, 32 bytes for 32bit runtime on
x86-64, and 40 bytes for 64bit runtime on x86-64. As such, we cannot safely
share an LMDB environment between 32 and 64bit Linux processes, even when using
MDB_VL32.
This problem doesn't affect Windows, platforms using SysV semaphores, or
platforms using POSIX named semaphores. I don't currently know whether this is a
problem on other platforms that support POSIX process-shared mutexes.
Hallvard has suggested that we add some additional LOCK_FORMAT bits to protect
against incompatible accesses. This would primarily be useful for the mdb_stat
command, which can still safely retrieve some useful information from an
environment without acquiring any mutexes. E.g., an MDB_VL32 build of mdb_stat
could retrieve most envinfo, statinfo, and readerinfo from a running 64bit
environment. It could not scan the freelist, scan all the names of named DBs, or
clean the reader list, since these operations all require taking the reader
mutex.
5 years, 6 months
Re: (ITS#8581) slapd-meta backend SSL negociation timeout
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms020706080404060907060004
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
louis.chanouha(a)univ-toulouse.fr wrote:
> OS: Debian 8 Jessie x64
> slapd: 2.4.40+dfsg-1+deb8u2
> gnutls: 3.3.8-6+deb8u4
Note that the Debian builds are an older version and AFAICS the GnuTLS wr=
apping code does
not receive much love.
Try again release 2.4.44 linked to OpenSSL e.g. by using the ltb-project =
builds or your
own custom build.
Ciao, Michael.
--------------ms020706080404060907060004
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
CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo
YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz
hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F
RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms
FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj
K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG
Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT
Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF
BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF
BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js
MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH
AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB
AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt
1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd
RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR
XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue
mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC
AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake
fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL
A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC
S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my
Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR
9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH
AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0
cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF
BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh
LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn
SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g
ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI
hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L
IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS
EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP
v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue
/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6
UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM
zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK
KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ
8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw
dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx
IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA1MTczNTMzWjAvBgkq
hkiG9w0BCQQxIgQg4NQP+omZGvsJczulvAUBlhaYlRBt9N6eXp48/EjfOKswbAYJKoZIhvcN
AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB
BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw
JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh
cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ
EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD
VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD
b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE
ggEARdz6AM0G9ncIBAk7l8ii/QR/W3Ovn0S97sRUobDoRu26k6byIsAl7vSgQSKAx2ExQL73
UjZtSaQQ3Bd99nPPAxGIMFIjZ/D55eB8t6+W61rTI7jhzuHifdG/XmLp4ELM0i+wfjFYMiiJ
hkGm8bpBIVlfh4rwZscrmfrTOwbJJT6/tCtH185mynXP8vxCA/31M78E3L01436GI6LtaJ8z
Z7HpkbKANlae4f7AIHv+aFU+tgkGbzFWcb6abDHYqANfxAeuKn6cRBEN/5mvhio7LjAM4qcU
xIxGb2aA5uySOtNdLtVh3hj9q3OXhZkM20/dCQU5PZxaThl4HpqbZH2QbwAAAAAAAA==
--------------ms020706080404060907060004--
5 years, 6 months
(ITS#8581) slapd-meta backend SSL negociation timeout
by louis.chanouha＠univ-toulouse.fr
Full_Name: Louis Chanouha
Version: 2.4.40
OS: Debian 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (90.76.56.40)
Hello,
I experience some problems with slapd-meta with ldaps backend.
gnuTLS (or openssl) negociation timeout seems not to be handled, and i can't
find any reference to modify this timeout on docs. My server becames
unresponsive (too many connexion slots) when a ssl-secured backend server time
out after TCP connexion establishment.
To reproduce the error, i have an meta directory configured like this:
database meta
suffix "dc=localauth"
rootdn "%n=Manager,dc=localauth"
rootpw XXX
uri "ldaps://localhost:666/ou=UT,dc=localauth"
lastmod off
suffixmassage "ou=UT,dc=localauth" "ou=people,dc=example,dc=fr"
timeout 1
conn-ttl 1
network-timeout 1
And i launch a netcat to listen to the 666 port:
nc -l -p 666
Then, this command never time out:
ldapwhoami -H ldap://YYYY:9009 -D uid=me,ou=UT,dc=localauth -W
Error does not happen when no ssl used ("timeout 1" option works well)
OS: Debian 8 Jessie x64
slapd: 2.4.40+dfsg-1+deb8u2
gnutls: 3.3.8-6+deb8u4
Sorry for my english, and thanks for the help,
Regards,
Louis Chanouha
University of Toulouse
5 years, 6 months
(ITS#8579) LMDB: me_fd should be O_CLOEXEC on POSIX systems
by lmb＠cloudflare.com
Full_Name: Lorenz Bauer
Version:
OS: Linux
URL:
Submission from: (NULL) (2a06:98c0:1000:8200:18fd:e772:495e:6163)
This is in some ways a follow up to ITS#8505. In the issue I argued that LMDB
did not deal well with fork/exec. Hallvard committed a fix in
04acac634a7b276332e2. I think the fix still has one major weakness: me_fd does
not have O_CLOEXEC set.
Now, Hallvard omitted this change on purpose. mdb_env_get_fd() exposes me_fd to
the user, so there could conceivably be client code out there which expects the
fd to persist across exec(). (Please correct my if I misunderstood your
argument.)
I believe that the correct action is to set O_CLOEXEC on me_fd by default, and
break such client code.
1. Using mdb_env_get_fd this way is Undefined Behaviour (according to the doc)
Before ITS#8505, the documentation made it sound like ANY use after fork() /
exec() is disallowed. At the same time, mdb_env_get_fd made no mention /
promises wrt exec() behaviour.
Adopting O_CLOEXEC in my opinion does not violate the API set out so far. We
can, in the opposite, clarify what is acceptable use (as Hallvard already has
done).
2. mdb_env_get_fd has inconsistent semantics across OSs
When creating file handles on Windows we pass NULL as the lpSecurityAttributes
argument to CreateFileW:
If this parameter is NULL, the handle returned by CreateFile cannot be
inherited by any child processes the application may create [...]
me_fd already has O_CLOEXEC on Windows.
3. Manually closing me_fd after fork() is not possible in all environments
Hallvard suggests calling fork(), close(mdb_env_get_fd()) and then exec() for
users which do not want to leak me_fd to child processes.
We use LMDB from the Go platform, which does not expose fork and exec separately
(due to the well-known pitfalls they have). We can't use Hallvard's suggestion
therefore.
4. me_fd can still be passed around by dup()ing the handle
If there are legitimate uses of passing the handle around, users can explicitly
dup the handle and then pass it on to child processes.
I hope my arguments are convincing enough to make the change before the next
release. The benefits are
* Consistent semantics between OS
* (In my view) saner defaults
* and a solution which works well across environments.
The downside is that we might break unknown client code. I can'c come up with a
use case of passing me_fd to children, so I suspect the risk is low.
The patch itself is trivial, and I'm happy to contribute it if desired.
Lorenz
5 years, 6 months
(ITS#8577) Accesslog overlay hangs slapd depending on module loading order
by mj＠netauth.com
Full_Name: Mike Jackson
Version: 2.4.44
OS: Oracle Linux Server release 7.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.157.185.162)
Same issue as Stroeder mentioned here:
http://www.openldap.org/lists/openldap-bugs/201111/msg00027.html
If accesslog.la is loaded before syncprov.la, slapd will stop accepting
connections immediately after accesslog overlay is added.
olcModuleLoad: {0}ppolicy.la
olcModuleLoad: {1}auditlog.la
olcModuleLoad: {2}back_ldap.la
olcModuleLoad: {3}unique.la
olcModuleLoad: {4}accesslog.la
olcModuleLoad: {5}syncprov.la
ldapadd -f
dn: oDatatabase={4}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {4}mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=log
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
olcDbMaxSize: 1073741824
olcDbMode: 0600
olcAccess: {0}to * by
dn.children="ou=global-admins,ou=admin-users,dc=foo,dc=net" read
dn: olcOverlay=accesslog,olcDatabase={4}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olccccessLogDB<ncn=log
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
olcAccessLogPurge: 7+00:00 1+00:00
5 years, 6 months
(ITS#8576) Broken LDAP_TAILQ_ macros
by hyc＠openldap.org
Full_Name: Howard Chu
Version: HEAD etc
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.235.15.200)
Submitted by: hyc
In commit 8ee824832844c16d4199f3aacd8b1d613933a7d5 we have "LDAP_TAILQ fix" but
no explanation of what was broken. In particular though, the LDAP_TAILQ_PREV
macro is now broken. It checks for foo == LDAP_TAILQ_FIRST(head) which becomes
foo == (head)->tqh_first but the initializer actually used foo =
&(head).tqh_first so this comparison will always be false.
I don't see any clear reason why these were changed from the originals. I'm
inclined to revert the change. Reverting will affect a few uses of
LDAP_TAILQ_LAST in back-ldap and back-meta but the other affected macros appear
to be unused in our source tree.
Tripped over this while attempting to use LDAP_TAILQ_PREV in new code.
5 years, 6 months
