Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms060502000406060901070508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
fumiyas(a)osstech.jp wrote:
> At Mon, 11 Jun 2012 21:30:18 +0200,
> Michael Str=F6der wrote:
>>>> Do I have to tweak the Makefile?
>>>
>>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC.
>>
>> I hoped that this would not be necessary and the module work include s=
omething
>> detected via autoconf before.
>=20
> Can you try the following Makefile?
>=20
> https://gist.github.com/2915450
This works much better.
And now the bind after Password Modify ext. op. also works!
???
Could you please submit a patch with your recent Makefile?
Ciao, Michael.
--------------ms060502000406060901070508
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC
BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG
EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM
MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF
MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M
VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K
b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/
kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB
1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC
EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0
Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw
QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1
c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/
BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3
LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2
KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj
Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M
MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK
KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR
GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4
B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ
FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx
QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw
ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF
MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl
ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ
MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV
BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz
IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt
5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z
5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH
hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1
3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst
smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB
BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv
dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p
dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ
dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB
MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E
gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k
ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy
MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/
Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE
m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV
0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz
UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9
ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X
iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx
CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU
QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD
bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjEzMDczMDAzWjAjBgkq
hkiG9w0BCQQxFgQUrungi4tWis9D11T/hGg7NPK0+MQwbAYJKoZIhvcNAQkPMV8wXTALBglg
hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP
MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL
ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl
ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS
oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD
VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl
bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE
ggEALHbs0wAx3r3but/uiE5O3lKc+27I4VhWvGrTxD8CHDtE8Xk4xA7CNiHjMMtoYWRWrSKw
VWMXXhEXwNN6ePT4CIu4UgBpvh5DsVnaOeRHspjv0+V1Dy0H0QmptzyEf1pjxhguIv181eRm
aZmKatgTBXTxj7aWrm1+N2ozuYXPVUSJCWXa2OcENnYc4Fm7XuAy0LDg0dqnaAxRgSlTQyu0
tEXBz5M7a0YJuCwjVMyf74f3hP/Z90CGIirnk96SKC9UutbYocWlck3F4KQkKhTR8A+Tx/Hv
M9EqRvWw7PxRGoRpSSjX7SdkRw0cUw5ZJtZX3UmYohz8Ks0v+8krldsgMgAAAAAAAA==
--------------ms060502000406060901070508--
10 years, 9 months
(ITS#7303) bdb/hdb search checks aliases unnecessarily
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD/RE24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (37.19.96.193)
Submitted by: hyc
If a search request has derefSearching set in the alias deref option, the
search_aliases() function walks thru a (potentially) large number of entries
checking to see if they are aliases, even if the objectclass index shows there
are no alias entries in the database. It should exit early instead.
The bug is also present to a lesser degree in back-mdb; the back-mdb version of
search_aliases() would only do a single unneeded entry lookup.
10 years, 9 months
(ITS#7302) mdb segfault when renaming entry
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.31
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.108.184.39)
Got the following segfault in mdb when renaming entry X to the same name as a
previously deleted entry Y.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f076d5c6700 (LWP 15510)]
0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at
./../../../libraries/libmdb/mdb.c:4516
4516 ./../../../libraries/libmdb/mdb.c: No such file or directory.
in ./../../../libraries/libmdb/mdb.c
(gdb) thr apply all bt full
Thread 5 (Thread 0x7f076ddc7700 (LWP 15509)):
#0 0x00007f1b7261c2d3 in epoll_wait () from /lib/libc.so.6
No symbol table info available.
#1 0x00000000004395d9 in slapd_daemon_task (ptr=0x2715d00) at daemon.c:2540
ns = 1
at = 0
nfds = 8
revents = 0x287e000
tvp = 0x7f076ddc4da0
cat = {tv_sec = 1339538180, tv_usec = 0}
i = 1
nwriters = 0
now = 1339537971
tv = {tv_sec = 209, tv_usec = 0}
tdelta = 1
rtask = 0x2d81950
l = 3
last_idle_check = 1339537880
ebadf = 0
tid = 0
#2 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#3 0x00007f1b7261bcdd in clone () from /lib/libc.so.6
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 4 (Thread 0x7f076d5c6700 (LWP 15510)):
#0 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at
./../../../libraries/libmdb/mdb.c:4516
leaf = 0x130000004c
rc = 0
#1 0x00007f1b6ea519b4 in mdb_cursor_del (mc=0x2e09880, flags=0) at
./../../../libraries/libmdb/mdb.c:4523
leaf = 0x50baacc
rc = 0
#2 0x00007f1b6ea42088 in mdb_dn2id_delete (op=0x2c0fc00, mc=0x2e09880, id=75)
at dn2id.c:235
key = {mv_size = 8, mv_data = 0x7f076d5c5468}
rc = 0
#3 0x00007f1b6ea31abc in mdb_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at
delete.c:336
mdb = 0x2e56000
pdn = {bv_len = 16, bv_val = 0x48e82c2 "dc=zimbra,dc=com"}
e = 0x48e8e90
p = 0x48e83f0
manageDSAit = 0
children = 0x2722ec0
entry = 0x2722f00
txn = 0x458c000
mc = 0x2e09880
opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x2e56000},
moi_txn = 0x458c000, moi_ref = 1, moi_flag = 0 '\000'}
moi = 0x7f076d5c5530
preread_ctrl = 0x0
ctrls = {0x0, 0x151f55373c8e5d00, 0x0, 0x48e8308, 0x7f076d5c5570,
0x27fb280}
num_ctrls = 0
parent_is_glue = 0
parent_is_leaf = 0
__PRETTY_FUNCTION__ = "mdb_delete"
#4 0x00000000004d4b08 in overlay_op_walk (op=0x2c0fc00, rs=0x7f076d5c5a10,
which=op_delete, oi=0x2c62d20, on=0x0) at backover.c:671
func = 0x7f1b6ec60cf8
rc = 32768
#5 0x00000000004d4d46 in over_op_func (op=0x2c0fc00, rs=0x7f076d5c5a10,
which=op_delete) at backover.c:723
oi = 0x2c62d20
on = 0x2c62780
be = 0x27589c0
db = {bd_info = 0x7f1b6ec60ca0, bd_self = 0x27589c0, be_ctrls =
"\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001",
'\000' <repeats 14 times>, "\001",
be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set =
{sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0,
sss_update_transport = 0,
sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0},
be_suffix = 0x2be7900, be_nsuffix = 0x2be78c0, be_schemadn = {bv_len = 0, bv_val
= 0x0}, be_schemandn = {
bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val =
0x2d5eda0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2d5ed80
"cn=config"}, be_rootpw = {bv_len = 0,
bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft =
-1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1,
lms_s_pr = 0,
lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl =
0x2c6f6c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn =
{bv_len = 0, bv_val = 0x0},
be_update_refs = 0x0, be_pending_csn_list = 0x456f610, be_pcl_mutex =
{__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
__spins = 0, __list = {
__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39
times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs =
0x7f1b6ec60aa0, be_private = 0x2e56000,
be_next = {stqe_next = 0x0}}
cb = {sc_next = 0x48e82e0, sc_response = 0x4d3840 <over_back_response>,
sc_cleanup = 0, sc_private = 0x2c62d20}
sc = 0x0
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#6 0x00000000004d4f2f in over_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at
backover.c:780
No locals.
#7 0x000000000046149c in fe_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at
delete.c:174
org_req_dn = {bv_len = 0, bv_val = 0x0}
org_ndn = {bv_len = 0, bv_val = 0x0}
org_managedsait = 41923200
org_req_ndn = {bv_len = 0, bv_val = 0x0}
org_dn = {bv_len = 0, bv_val = 0x0}
repl_user = 0
pdn = {bv_len = 0, bv_val = 0x0}
op_be = 0x27589c0
bd = 0x75fdc0
#8 0x000000000046110f in do_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at
delete.c:95
dn = {bv_len = 26, bv_val = 0x4577da5 "ou=people,dc=zimbra,dc=com"}
#9 0x000000000043d8c9 in connection_operation (ctx=0x7f076d5c5b50,
arg_v=0x2c0fc00) at connection.c:1150
rc = 80
cancel = 0
op = 0x2c0fc00
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798,
sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un =
{sru_search = {r_entry = 0x0,
r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended =
{r_rspoid = 0x0, r_rspdata = 0x0}},
sr_flags = 0}
tag = 74
opidx = SLAP_OP_DELETE
conn = 0x2f6b440
memctx = 0x27fb280
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#10 0x000000000043de67 in connection_read_thread (ctx=0x7f076d5c5b50, argv=0x13)
at connection.c:1286
rc = 0
cri = {op = 0x2c0fc00, func = 0, arg = 0x0, ctx = 0x7f076d5c5b50, nullop
= 0}
s = 19
#11 0x00007f1b73db5cc9 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at
tpool.c:688
pool = 0x273c1c0
task = 0x4576680
work_list = 0x273c258
ctx = {ltu_id = 139669876270848, ltu_key = {{ltk_key = 0x43d429,
ltk_data = 0x2c78200, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key =
0x4b388f, ltk_data = 0x27fb280,
ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad,
ltk_data = 0x0, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000,
ltk_data = 0x457e000,
ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key =
0x7f1b6ea384d9, ltk_data = 0x49e8000, ltk_free = 0x7f1b6ea38491
<scope_chunk_free>}, {ltk_key = 0x4daa000,
ltk_data = 0x4581400, ltk_free = 0x7f1b6ea4492b
<mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x65f2000, ltk_free =
0x7f1b6ea3aad1 <search_stack_free>}, {
ltk_key = 0x0, ltk_data = 0x4579200, ltk_free = 0}, {ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}}
kctx = 0x0
i = 32
keyslot = 854
hash = 2665057110
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#12 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#13 0x00007f1b7261bcdd in clone () from /lib/libc.so.6
No symbol table info available.
#14 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 3 (Thread 0x7ef36cdc3700 (LWP 15671)):
#0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0,
mutex=0x273c1c8) at thr_posix.c:277
No locals.
#2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at
tpool.c:675
pool = 0x273c1c0
task = 0x0
work_list = 0x273c258
ctx = {ltu_id = 139583968524032, ltu_key = {{ltk_key = 0x43d429,
ltk_data = 0x2c04400, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key =
0x4b388f, ltk_data = 0x2bc1200,
ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad,
ltk_data = 0x2c0e000, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key =
0x4daa000, ltk_data = 0x4582e00,
ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key =
0x7f1b6ea384d9, ltk_data = 0x51ee000, ltk_free = 0x7f1b6ea38491
<scope_chunk_free>}, {ltk_key = 0x45e6000,
ltk_data = 0x4586200, ltk_free = 0x7f1b6ea4492b
<mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x55ee000, ltk_free =
0x7f1b6ea3aad1 <search_stack_free>}, {
ltk_key = 0x0, ltk_data = 0x457a400, ltk_free = 0}, {ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}}
kctx = 0x0
i = 32
keyslot = 464
hash = 81037776
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (Thread 0x7ef36c5c2700 (LWP 15672)):
#0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0,
mutex=0x273c1c8) at thr_posix.c:277
No locals.
#2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at
tpool.c:675
pool = 0x273c1c0
task = 0x0
work_list = 0x273c258
ctx = {ltu_id = 139583960131328, ltu_key = {{ltk_key = 0x43d429,
ltk_data = 0x2c04500, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key =
0x4b388f, ltk_data = 0x2bc1300,
ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad,
ltk_data = 0x2c0e800, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key =
0x45e6000, ltk_data = 0x458e000,
ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key =
0x7f1b6ea384d9, ltk_data = 0x75f6000, ltk_free = 0x7f1b6ea38491
<scope_chunk_free>}, {ltk_key = 0x7f1b6ea3aaf4,
ltk_data = 0x78f6000, ltk_free = 0x7f1b6ea3aad1
<search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x457b600, ltk_free = 0},
{ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 25 times>}}
kctx = 0x0
i = 32
keyslot = 576
hash = 1606749760
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7f1b744e4720 (LWP 15508)):
#0 0x00007f1b728c003d in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00007f1b73db71ff in ldap_pvt_thread_join (thread=139669884663552,
thread_return=0x0) at thr_posix.c:197
No locals.
#2 0x000000000043a7ff in slapd_daemon () at daemon.c:2930
i = 0
rc = 0
#3 0x0000000000416d7f in main (argc=9, argv=0x7fffc49fe378) at main.c:1012
i = 9
no_detach = 0
rc = 0
urls = 0x271a000 "ldap://zre-ldap003.eng.vmware.com:389 ldapi:///"
username = 0x2714020 "root"
groupname = 0x0
sandbox = 0x0
syslogUser = 128
pid = 0
waitfds = {10, 11}
g_argc = 9
g_argv = 0x7fffc49fe378
configfile = 0x0
configdir = 0x2712040 "/opt/zimbra/data/ldap/config"
serverName = 0x7fffc49ffd92 "slapd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x4f9928 ""
l = 139755887037800
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
10 years, 9 months
Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com
--On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote:
> quanah(a)OpenLDAP.org wrote:
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.4.31
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (75.108.184.39)
>>
>>
>> LDAP URI handling via SRV records is not in the library. In
>> particular, an OpenLDAP library client that specifies a
>> (correctly formed or otherwise) LDAP URI of the form:
>>
>> ldap:///dc=example,dc=com/
>>
>> will not be connected to the LDAP servers found in the SRV records
>> for _ldap._tcp.example.com. That code is only in the ldapsearch(1)
>> and related tools.
>>
>> The existence of the low-level support functions in the library is
>> of no help to users who want to specify URIs that resolve to the
>> underlying LDAP servers via SRV records.
>
> Tough luck. Currently ldap:/// means localhost. Changing the library
> behavior here would be a pretty drastic incompatible change and would
> break pretty much all existing software. This has been discussed and shot
> down before, and rejecting this request is the only correct outcome for
> this ITS.
What about an ldap_set_option() parameter for enabling it?
>> Also, the SRV -> host:port list lookup code that is in the library
>> (but not tied to the libraries connection establishment code) is
>> broken, it ignores the weight and priority which is not a good
>> idea, the published SRV priorities and weights must not be ignored.
>
> priorities/weights are already the subject of ITS#7027.
Ok, so will 7027 be committed, since there is a patch already provided? ;)
The discussion around this started at
<http://archives.neohapsis.com/archives/postfix/2012-06/0183.html>
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 9 months
Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by hyc＠symas.com
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.31
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.108.184.39)
>
>
> LDAP URI handling via SRV records is not in the library. In
> particular, an OpenLDAP library client that specifies a
> (correctly formed or otherwise) LDAP URI of the form:
>
> ldap:///dc=example,dc=com/
>
> will not be connected to the LDAP servers found in the SRV records
> for _ldap._tcp.example.com. That code is only in the ldapsearch(1)
> and related tools.
>
> The existence of the low-level support functions in the library is
> of no help to users who want to specify URIs that resolve to the
> underlying LDAP servers via SRV records.
Tough luck. Currently ldap:/// means localhost. Changing the library behavior
here would be a pretty drastic incompatible change and would break pretty much
all existing software. This has been discussed and shot down before, and
rejecting this request is the only correct outcome for this ITS.
> Also, the SRV -> host:port list lookup code that is in the library
> (but not tied to the libraries connection establishment code) is
> broken, it ignores the weight and priority which is not a good
> idea, the published SRV priorities and weights must not be ignored.
priorities/weights are already the subject of ITS#7027.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 9 months
Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com
--On Tuesday, June 12, 2012 6:09 PM +0000 quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.31
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.108.184.39)
Note: Filed on behalf of the Postfix authors.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 9 months
(ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.31
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.108.184.39)
LDAP URI handling via SRV records is not in the library. In
particular, an OpenLDAP library client that specifies a
(correctly formed or otherwise) LDAP URI of the form:
ldap:///dc=example,dc=com/
will not be connected to the LDAP servers found in the SRV records
for _ldap._tcp.example.com. That code is only in the ldapsearch(1)
and related tools.
The existence of the low-level support functions in the library is
of no help to users who want to specify URIs that resolve to the
underlying LDAP servers via SRV records.
Also, the SRV -> host:port list lookup code that is in the library
(but not tied to the libraries connection establishment code) is
broken, it ignores the weight and priority which is not a good
idea, the published SRV priorities and weights must not be ignored.
10 years, 9 months
Re: (ITS#7300) ACLs
by quanah＠zimbra.com
--On Tuesday, June 12, 2012 5:57 PM +0000 andre.cardinal(a)bell.ca wrote:
> Full_Name: Andre Cardinal
> Version: 2.4.30
> OS: Red Hat 5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (206.47.249.246)
This is not a bug report. This ITS will be closed.
If you have usage questions, please use the openldap-technical(a)openldap.org
mailing list.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 9 months
(ITS#7300) ACLs
by andre.cardinal＠bell.ca
Full_Name: Andre Cardinal
Version: 2.4.30
OS: Red Hat 5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (206.47.249.246)
I have the following ACL set up in slapd.conf
access to dn.base=""
by * read
access to attrs=GCSRAAllow,GCSRAGroup,GCSRASubjectdn,userpassword
by dn="cn=ProvAdmin,ou=GCSRAAdmin,o=gc,c=ca" write
by dn="cn=gateAdmin1,ou=GCSRAAdmin,o=gc,c=ca" read
by dn="cn=gateAdmin2,ou=GCSRAAdmin,o=gc,c=ca" read
slapacl -f /usr/local/etc/openldap/slapd.conf -D
cn=provadmin,ou=gcsraadmin,o=gc,c=ca -b ou=gcsrausers,o=gc,c=ca gcsraallow
authcDN: "cn=provadmin,ou=gcsraadmin,o=gc,c=ca"
GCSRAAllow: write(=wrscxd)
However any modify I try returns:
modifying entry "GCSRASubjectDN=my636-test,ou=GCSRAUsers,o=gc,c=ca"
ldap_modify: Insufficient access (50)
10 years, 9 months
