[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9192
Bug ID: 9192
Summary: slapo-rwm: assert triggered with invalid UUID filter
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
slapo-rwm triggers an assert when a filter with an invalid UUID syntax is used.
For example:
/opt/symas/bin/ldapsearch -x -H ldaps://ldap0.example.com -D
"cn=admin,dc=example,dc=com" -W -b dc=example,dc=com
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter:
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
# requesting: ALL
#
The above search will trigger an assert. Note that idmUUID is a custom
attribute defined as:
# idmUUID
attributetype ( 1.3.6.1.4.1.29179.2.3.3
NAME 'idmUUID'
DESC 'RFC4122 Univeral Unique Identifier for idM'
EQUALITY uuidMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
which is using the RFC4530 definition for UUID.
On the slapd side, we see:
#4 0x0000000000468650 in UUIDNormalize (usage=<optimized out>,
syntax=<optimized out>, mr=<optimized out>, val=0x7f1c58003110,
normalized=0x7f1c677fc5c0, ctx=<optimized out>)
at /home/build/sold/openldap/servers/slapd/schema_init.c:3019
No locals.
#5 0x00007f447599c55d in map_attr_value (dc=dc@entry=0x7f1c677fc730,
adp=adp@entry=0x7f1c677fc658, mapped_attr=mapped_attr@entry=0x7f1c677fc660,
value=0x7f1c58003110,
mapped_value=mapped_value@entry=0x7f1c677fc670, memctx=0x7f1c58002810,
remap=0) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:471
vtmp = {bv_len = 0, bv_val = 0x0}
freeval = 0
ad = 0x1947630
mapping = 0x0
#6 0x00007f447599ccc6 in rwm_int_filter_map_rewrite
(op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=0x7f1c58003170,
fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:559
i = <optimized out>
p = <optimized out>
ad = 0x1947630
atmp = {bv_len = 7, bv_val = 0x1900bb0 "idmUUID"}
vtmp = {bv_len = 139759712219536, bv_val = 0x7f1c58003240 "c"}
tmp = <optimized out>
ber_bvfalse = {bv_len = 18, bv_val = 0x7f447599f816
"(!(objectClass=*))"}
ber_bvtf_false = {bv_len = 3, bv_val = 0x7f447599f829 "(|)"}
ber_bvtrue = {bv_len = 15, bv_val = 0x7f447599f802 "(objectClass=*)"}
ber_bvtf_true = {bv_len = 3, bv_val = 0x7f447599f812 "(&)"}
ber_bverror = {bv_len = 9, bv_val = 0x7f447599f7f8 "(?=error)"}
ber_bvunknown = {bv_len = 11, bv_val = 0x7f447599f7ec "(?=unknown)"}
ber_bvnone = {bv_len = 8, bv_val = 0x7f447599f82d "(?=none)"}
len = <optimized out>
__PRETTY_FUNCTION__ = "rwm_int_filter_map_rewrite"
#7 0x00007f447599d7a8 in rwm_filter_map_rewrite (op=op@entry=0x7f1c580028f0,
dc=dc@entry=0x7f1c677fc730, f=<optimized out>, fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:824
rc = <optimized out>
fdc = <optimized out>
ftmp = {bv_len = 26355712, bv_val = 0x7f4475224500 "\002"}
#8 0x00007f4475999c5b in rwm_op_search (op=0x7f1c580028f0, rs=0x7f1c677fda60)
at /home/build/sold/openldap/servers/slapd/overlays/rwm.c:976
on = 0x1922620
rwmap = 0x1922800
rc = 0
dc = {rwmap = 0x1922800, conn = 0x7f4475224500, ctx = 0x7f447599f090
"searchFilterAttrDN", rs = 0x7f1c677fda60}
fstr = {bv_len = 0, bv_val = 0x0}
f = 0x0
an = 0x0
text = 0x0
roc = 0x7f1c58003218
#9 0x000000000049776a in overlay_op_walk (op=op@entry=0x7f1c580028f0,
rs=rs@entry=0x7f1c677fda60, which=which@entry=op_search, oi=oi@entry=0x1924430,
on=0x1922620)
at /home/build/sold/openldap/servers/slapd/backover.c:671
func = 0x1922678
rc = 32768
#10 0x00000000004978be in over_op_func (op=0x7f1c580028f0, rs=0x7f1c677fda60,
which=op_search) at /home/build/sold/openldap/servers/slapd/backover.c:747
oi = 0x1924430
on = <optimized out>
be = 0x728420 <slap_frontendDB>
db = {bd_info = 0x1922620, bd_self = 0x728420 <slap_frontendDB>,
be_ctrls = "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times>,
be_flags = 768, 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 = 0x18cb690, be_nsuffix = 0x18cb6e0, be_schemadn = {bv_len
= 12, bv_val = 0x1955c20 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val =
0x1955370 "cn=subschema"}, be_rootdn = {
bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0},
be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit =
{lms_t_soft = 3600, lms_t_hard = 0,
lms_s_soft = 50, 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 = 0x1925890,
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 = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0,
__elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size =
'\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0,
be_cf_ocs = 0x7200e8 <cf_ocs+392>, be_private = 0x0,
be_next = {stqe_next = 0x18cbcc0}}
sc = <optimized out>
cb = 0x7f1c580031e8
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#11 0x0000000000431006 in do_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at
/home/build/sold/openldap/servers/slapd/search.c:247
base = {bv_len = 14, bv_val = 0x7f1c580025c7 "dc=example,dc=com"}
siz = 0
off = 0
i = <optimized out>
#12 0x000000000042ede5 in connection_operation (ctx=ctx@entry=0x7f1c677fdbd0,
arg_v=arg_v@entry=0x7f1c580028f0) at
/home/build/sold/openldap/servers/slapd/connection.c:1167
rc = 80
cancel = <optimized out>
op = 0x7f1c580028f0
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0,
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 = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f4475224500
memctx = 0x7f1c58002810
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#13 0x000000000042f0ea in connection_read_thread (ctx=0x7f1c677fdbd0,
argv=0x16) at /home/build/sold/openldap/servers/slapd/connection.c:1314
rc = <optimized out>
cri = {op = 0x7f1c580028f0, func = 0x0, arg = 0x0, ctx = <optimized
out>, nullop = <optimized out>}
s = <optimized out>
#14 0x00007f447a585353 in ldap_int_thread_pool_wrapper (xpool=0x18b1340) at
/home/build/sold/openldap/libraries/libldap_r/tpool.c:963
pq = 0x18b1340
pool = 0x18b1250
task = 0x7f1c68000da0
work_list = <optimized out>
ctx = {ltu_pq = 0x18b1340, ltu_id = 139759972247296, ltu_key =
{{ltk_key = 0x42cbf0 <conn_counter_init>, ltk_data = 0x7f1c58002700, ltk_free =
0x42ccb0 <conn_counter_destroy>}, {
ltk_key = 0x47fef0 <slap_sl_mem_init>, ltk_data = 0x7f1c58002810,
ltk_free = 0x47fdb0 <slap_sl_mem_destroy>}, {ltk_key = 0x1ae4a40, ltk_data =
0x7f1c58102f30,
ltk_free = 0x7f44763ff550 <mdb_reader_free>}, {ltk_key = 0x4416f0
<slap_op_free>, ltk_data = 0x0, ltk_free = 0x441650 <slap_op_q_destroy>},
{ltk_key = 0x0, ltk_data = 0x7f1c58000a80,
ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}
<repeats 27 times>}}
kctx = <optimized out>
keyslot = <optimized out>
hash = <optimized out>
pool_lock = 0
freeme = 0
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#15 0x00007f4478d42ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#16 0x00007f4478a6b8cd in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week, 6 days
[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/m...
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 weeks, 1 day
[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9197
Bug ID: 9197
Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a customer:
In order to communicate via the LB managed writable ldap, we have to ensure
that an idle connection is periodically refreshed. If we do not, the LB will
silently drop the connection after 5 minutes.
Therefore to combat that I set an olcIdleTimeout on the writable server so that
the chain cached connections will be removed before the LB timeout hits.
However the slapo-ldap client goes into CLOSE_WAIT state, which causes
subsequent ldapmodify updates being brokered by the read only instance to fail
with err=80. There appear to be a few bugs filed on this in the past against
slapd-ldap, but it's not clear if we may be hitting the same issue, or if this
is a new one.
I've also connected the read only instances directly to the writable ldap
instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT
issue is caused by the LB
These were the other threads I found as I started looking for this problem,
these are using the ldap-proxy though I think:
https://www.openldap.org/lists/openldap-technical/201301/msg00323.html
http://www.openldap.org/lists/openldap-software/201004/msg00060.html
https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html
The LB we have seems to be set to forget connections that last over 5 min per
the setting, so the 240:10:30 seemed like it should have worked and I just
thought it wasn't working because in the man page the text "Only some systems
support the customization of these values" is present. however after setting
keepalive to 60:10:30 did I maintain a stable connection, so there may be other
network settings at play I'm not aware of.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 weeks, 6 days
[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 1 week
[Bug 9194] New: slapd-ndb: Remove backend for the 2.5 release
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9194
Bug ID: 9194
Summary: slapd-ndb: Remove backend for the 2.5 release
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Remove the slapd-ndb backend for the 2.5 release, as it was never finished and
development on it has ceased.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 months, 1 week
[Bug 9191] New: libraries\liblutil\meter.c have a bad function lutil_meter_update, maybe divide 0
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9191
Bug ID: 9191
Summary: libraries\liblutil\meter.c have a bad function
lutil_meter_update, maybe divide 0
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: digpython(a)163.com
Target Milestone: ---
int
lutil_meter_update (
lutil_meter_t *meter,
size_t position,
int force)
{
static const double display_rate = 0.5;
double frac, cycle_length, speed, now;
time_t remaining_time, elapsed;
int rc;
assert( meter != NULL );
lutil_get_now( &now );
if ( !force && now - meter->last_update < display_rate ) return 0;
frac = ((double)position) / ((double) meter->goal_value);
elapsed = now - meter->start_time;
if (frac <= 0.0) return 0;
if (frac >= 1.0) {
rc = meter->display->display_update(
&meter->display_data,
1.0,
0,
(time_t) elapsed,
((double)position) / elapsed);
} else {
...
}
--
You are receiving this mail because:
You are on the CC list for the bug.
4 months, 1 week
[Bug 9185] New: glue entry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9185
Bug ID: 9185
Summary: glue entry
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
5 months, 1 week
[Bug 9188] New: Expose transaction mt_flags?
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9188
Bug ID: 9188
Summary: Expose transaction mt_flags?
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: code(a)doriantaylor.com
Target Milestone: ---
Created attachment 631
--> https://bugs.openldap.org/attachment.cgi?id=631&action=edit
patch in mdb_txn_flags
I have taken over maintenance of the Ruby bindings to LMDB
(https://github.com/doriantaylor/lmdb/tree/reconcile-2.7) and am currently
fleshing out the transaction code. What I am finding is something of a leaky
abstraction: in the current configuration it is essentially too easy to write
Ruby code that messes up the internal transaction bookkeeping of the binding.
I am still trying to get my bearings on both the binding and the LMDB library
itself, but it seems it would be generally useful if it was possible to
determine whether a given transaction was read-only, so for example to prevent
one from opening a read-write transaction beneath a read-only one.
As such, I propose the enclosed patch that adds an `mdb_txn_flags` function,
which returns the `mt_flags` field. This would enable downstream developers to
tell if a given transaction was, among other things, read-only, and behave
accordingly.
--
You are receiving this mail because:
You are on the CC list for the bug.
10 months, 2 weeks