[Issue 9284] New: Need man page for vc contrib overlay
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
8 hours, 29 minutes
[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9337
Issue ID: 9337
Summary: Slapd crash with lastbind overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: frederic.poisson(a)admin.gmessaging.net
Target Milestone: ---
Hello,
I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1
master and 1 replica), and when i activate the lastbind overlay. The replica
server crash like this :
slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in
slapd[400000+1d8000]
The database is this one with overlay loaded :
dn: cn=module{0},cn=config
olcModuleLoad: {0}sssvlv.la
olcModuleLoad: {1}ppolicy.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}lastbind.la
olcModuleLoad: {4}pw-sha2.la
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcUpdateRef: ldap://master.server:389/
If i add this configuration it crash :
dn: olcOverlay={2}lastbind
objectClass: olcOverlayConfig
objectClass: olcLastBindConfig
olcOverlay: {2}lastbind
olcLastBindPrecision: 60
olcLastBindForwardUpdates: TRUE
Does the release 2.5.51 or 2.5.52 could solve this issue ?
Regards,
--
You are receiving this mail because:
You are on the CC list for the issue.
9 hours, 10 minutes
[Bug 9200] New: 2.4 to 2.5 upgrade documentation
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9200
Bug ID: 9200
Summary: 2.4 to 2.5 upgrade documentation
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: blocker
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For the 2.5 release, we need to document the upgrade procedures for moving from
OpenLDAP 2.4 to OpenLDAP 2.5.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 hours, 10 minutes
[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 days, 8 hours
[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295
Summary: ppolicy and replication: pwdLockedTime replication
fails to replicate
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If you have the following setup, a replica will hit an error during
replication.
a) ppolicy is configured on provider(s) and replicas. Replica has
schemachecking=on in its syncrepl configuration
b) account gets locked on the replica, so pwdAccountLockedTime is set on the
replica but not on the provider(s)
c) admin does a MOD/ADD op against a provider for the user entry to add a value
to pwdAccountLockedTime
dn: ...
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: ...
d) provider accepts this modification.
e) replica rejects this modification because the resulting change means that
there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should
be treated as a replace OP instead of an ADD op
--
You are receiving this mail because:
You are on the CC list for the issue.
4 weeks
[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9272
Issue ID: 9272
Summary: Invalid search results for subordinate/glued database
Product: OpenLDAP
Version: 2.4.47
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Here is a trivial test case. Look at the following bunch of glued
dit's/databases, declared in this order:
| suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=2,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=T # master database, has two entries, top-level
| ` ou=1 # ... and this child entry
let's query the united database:
| $ ldapsearch -b ou=1,ou=T -s sub '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
| dn: ou=b,ou=1,ou=T
Nice! But wait, what if ...
| $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
|
| # pagedresults: cookie=//////////8=
... BANG! ...
| Server is unwilling to perform (53)
The problem is the glue_op_search(), which has issues
* different parts of code make different assumptions about data structures
* different parts of code track state inconsistently
* code that looks like a highly probably dead code
I mean that likely possible to build another bug-triggering test cases, and
glue_op_search() needs not just a fix of the bug above, but intense cleaning
and structuring.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month
[Bug 9243] New: back-perl configure should test linking with libperl
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9243
Bug ID: 9243
Summary: back-perl configure should test linking with libperl
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
./configure --enable-perl && make
[...]
checking for perl... /usr/bin/perl
[...]
libtool: link: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o
connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o
result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o
value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o
str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o
schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o
mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o
root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o
operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o
ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o
slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o
txn.o slapschema.o slapmodify.o version.o -Wl,-E -fstack-protector-strong
-pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a
../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a
../../libraries/libldap_r/.libs/libldap_r.a
/home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a -L/usr/local/lib
-L/usr/lib/x86_64-linux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt
-lresolv -pthread
/usr/bin/ld: cannot find -lperl
collect2: error: ld returned 1 exit status
It should probably test compiling and linking a program with the detected
CPPFLAGS and LDFLAGS.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 month, 1 week
[Issue 9382] New: client tools ldapvc.c tracks criticality but doesn't use it
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9382
Issue ID: 9382
Summary: client tools ldapvc.c tracks criticality but doesn't
use it
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In clients/toolsldapv.c, we have:
switch ( i ) {
char *control, *cvalue;
int crit;
...
case 'E': /* vc extension */
crit = 0;
if( optarg[0] == '!' ) {
crit = 1;
and then we never use "crit" again. It would appear the intention was to
determine whether or not this control is marked critical and then do something
based on that, but there is in fact nothing ever done.
This leads to a warning that crit is set but unused.
If the criticality of the control doesn't matter, than this variable should be
eliminated. If it does matter, then the missing code needs to be added.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month, 1 week
[Issue 9288] New: slapd service stops suddenly but generates crash file
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9288
Issue ID: 9288
Summary: slapd service stops suddenly but generates crash file
Product: OpenLDAP
Version: 2.4.49
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tekkitan(a)gmail.com
Target Milestone: ---
System: t3.small AWS instance 2VCPU 2GB RAM
OS: Ubuntu 20.04 (was happening on 16.04 as well)
Package Version: 2.4.49+dfsg-2ubuntu1.2
We've been having this weird problem with slapd between Ubuntu 16.04 and Ubuntu
20.04 where slapd will suddenly stop according to syslog but will also generate
a crash file within apport. We thought it was due to some weird stuff we were
doing in the 16.04 version (2.4.42+dfsg-2ubuntu3.8), but we deployed a new LDAP
proxy in 20.04 (2.4.49+dfsg-2ubuntu1.2) which appears to have the same issue so
I am reporting it and hoping for guidance as we use this proxy for our
corporate VPN.
Below is the backtrace which was the same from both proxy systems, but this one
is from the 20.04 version as that is our current system in use:
root@useldap02:~/_usr_sbin_slapd.0.crash# apport-retrace --stdout
/var/crash/_usr_sbin_slapd.0.crash
--- stack trace ---
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 140488162916432, 140488307736576, 140487911640016,
140487911640117, 140487911640016, 140487911640016, 140487911640147,
140487911640316, 140487911640016, 140487911640316, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007fc5f3043859 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x2, sa_sigaction = 0x2},
sa_mask = {__val = {131, 4, 99, 0, 0, 140488164070405, 0, 21474836480,
140488121483504, 0, 140488164102160, 0, 6703301646461552640, 140488164070405,
140488165695488, 140488164087176}}, sa_flags = -235332728, sa_restorer = 0xbf}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007fc5f3043729 in __assert_fail_base (fmt=0x7fc5f31d9588 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=0x7fc5f1f91953
"!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88
"../../../../../servers/slapd/back-ldap/bind.c", line=191, function=<optimized
out>) at assert.c:92
str = 0x7fc5c410a280 "@Q\021\344\305\177"
total = 4096
#3 0x00007fc5f3054f36 in __GI___assert_fail (assertion=0x7fc5f1f91953
"!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88
"../../../../../servers/slapd/back-ldap/bind.c", line=191,
function=0x7fc5f1f921a0 "ldap_back_conn_delete") at assert.c:101
No locals.
#4 0x00007fc5f1f807c7 in ldap_back_conn_delete () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#5 0x00007fc5f1f814a4 in ?? () from /usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#6 0x00007fc5f1f815ad in ldap_back_release_conn_lock () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#7 0x00007fc5f1f833bc in ldap_back_retry () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#8 0x00007fc5f1f7ec0b in ldap_back_search () from
/usr/lib/ldap/back_ldap-2.4.so.2
No symbol table info available.
#9 0x000055b87105cc88 in overlay_op_walk ()
No symbol table info available.
#10 0x000055b87105cdb7 in ?? ()
No symbol table info available.
#11 0x000055b870fef80d in fe_op_search ()
No symbol table info available.
#12 0x000055b870fef034 in do_search ()
No symbol table info available.
#13 0x000055b870fec6ed in ?? ()
No symbol table info available.
#14 0x000055b870fed22c in ?? ()
No symbol table info available.
#15 0x00007fc5f32e7a03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2
No symbol table info available.
#16 0x00007fc5f3219609 in start_thread (arg=<optimized out>) at
pthread_create.c:477
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140488121493248,
-8220430158823943899, 140488129874654, 140488129874655, 140488129874784,
140488121490880, 8241811018110734629, 8241811687867814181}, mask_was_saved =
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 0}}}
not_first_call = 0
#17 0x00007fc5f3140103 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
This is usually what we see within syslog when slapd stops:
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH
base="ou=people,dc=company,dc=com" scope=2 deref=0
filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))"
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH attr=cn uid sn
mail proxyAddresses userPrincipalName fullName displayName description
objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day
fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl
fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod
fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods
fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods
fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret
fw1ISAKMP-DataEncMethod givenName surname
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH
base="ou=groups,dc=company,dc=com" scope=2 deref=0
filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))"
Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH attr=cn uid sn
mail proxyAddresses userPrincipalName fullName displayName description
objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day
fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl
fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod
fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods
fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods
fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret
fw1ISAKMP-DataEncMethod givenName surname
Jul 11 00:49:34 useldap02 slapd[28099]: * Stopping OpenLDAP slapd
Jul 11 00:49:34 useldap02 slapd[28099]: ...done.
Jul 11 00:49:34 useldap02 systemd[1]: slapd.service: Succeeded.
Note that a lot of these attributes being searched for (all the fw1*
attributes) do not exist within our LDAP. Not sure if that would be the cause.
Thank you for any help that can be provided.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month, 1 week
[Issue 9270] New: Admin guide: Add detailed information on indexing
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9270
Issue ID: 9270
Summary: Admin guide: Add detailed information on indexing
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
It would be useful to outline what the different types of indexing options do,
and when they are useful, in the admin guide.
For example:
presence indexing is only useful if looking to find entries with a given
attribute, when generally < 50% of the entries in the DB have an instance of
that attribute.
equality indexing would not be particularly useful on an attribute that exists
in most every entry, and the attribute always has the same value
etc.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month, 1 week