[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.
2 days, 12 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.
2 days, 17 hours
[Issue 9396] New: Docs might recommend applicationProcess for ppolicy entries
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9396
Issue ID: 9396
Summary: Docs might recommend applicationProcess for ppolicy
entries
Product: OpenLDAP
Version: unspecified
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 779
--> https://bugs.openldap.org/attachment.cgi?id=779&action=edit
Suggested doc patch
Hello,
The ppolicy section of the Admin Guide does not say why the "people" object
class is present in the example policy entry.
I suggest that the docs explain. Otherwise the reader is left wondering why
the particular choice of structural object class was made. The less informed
reader is left wondering why a second object class is required at all.
I also suggest that instead of the "people" object class,
that the applicationProcess object class be used in the example to provide the
structural object class the entry requires.
The slapo-ppolicy man page might also provide guidance.
Attached is a suggested patch, provided so that you have something to work
from. If you're not happy with the patch go ahead and discard it, I'm not
advocating
any particular wording.
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 issue.
5 days, 13 hours
[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.
6 days, 14 hours
[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9468
Issue ID: 9468
Summary: slapd-ldap does anonymous bind even if rebind-as-user
is set
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
When back-ldap retries bind operation after connection retry, it will do it as
anonymous even if rebind-as-user is set to yes.
Expected behavior is that (re)bind is done with user's credentials from the
initial bind operation.
I observed following (Warning: I might have understood details of the code
incorrectly):
When rebind-as-user is set and bind operation from client is processed, proxy
will copy the credentials to ldapconn_t representing the remote LDAP
connection. When remote LDAP connection is closed (e.g. by the proxy itself due
to timeout), the bind credentials information is lost when freeing the old
ldapconn_t. At this point, client still holds the connection to proxy and is
unaware of the remote connection being lost. Proxy then re-establishes the
connection and "synthetically" generates new bind itself, but since it does not
have the credentials stored in memory anymore, it sends anonymous bind on
behalf of the client.
As a side effect, slapd currently crashes if remote server does not allow
anonymous bind and responds with InvalidCredentials instead. The crash is due
to assert(), which is handled in separate issue
https://bugs.openldap.org/show_bug.cgi?id=9288
--
You are receiving this mail because:
You are on the CC list for the issue.
6 days, 17 hours
[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.
6 days, 17 hours
[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.
1 week, 1 day
[Issue 9471] New: Add RBAC overlay to core
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its RBAC overlay to core
The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 6 days
[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 week, 6 days
[Issue 9445] New: ITS#9339/1748ec59a crashes slapd on ip connect in tcpwrappers
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9445
Issue ID: 9445
Summary: ITS#9339/1748ec59a crashes slapd on ip connect in
tcpwrappers
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
When openldap is configured with tcpwrappers,
servers/slapd/daemon.c`slap_listener() calls:
> hosts_ctl("slapd", dnsname != NULL ? dnsname : SLAP_STRING_UNKNOWN,
> peeraddr, ...
where `peeraddr' must be client ip addr or literal "unknown" string.
Commit [2020-09-06 1748ec59a ITS#9339 Add syncrepl status to cn=monitor] is
made so that `peeraddr' contains fixed NULL value.
This causes immediate crash of slapd inside tcpwrappers library when client
connects using ip protocol at least on Solaris x86-64.
I did not verify this on linux, but even if slapd doesn't crash on linux, then
tcpwrappers do not work as expected anyway.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 6 days