https://bugs.openldap.org/show_bug.cgi?id=9470
Issue ID: 9470
Summary: Add homedir 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 homedir overlay as a core overlay
Home directory provisioning overlay
The homedir overlay causes slapd to notice changes involving RFC-2307bis style
user-objects and make appropriate changes to the local filesystem. This can be
performed on both master and replica systems, so it is possible to perform
remote home directory provisioning.
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9482
Issue ID: 9482
Summary: slapi_int_get_plugins() may return uninitialized data
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: ---
... because
> if ( be == NULL ) {
> goto done;
> }
returns before output variable ppFuncPtrs has been initialized.
This may be not affect openldap code, but, if I understand correctly,
slapi_int_get_plugins() is part of api and may affect 3rd party.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9479
Issue ID: 9479
Summary: asyncmeta: test074 failure to terminate
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: ---
When the asyncmeta backend is enabled in master test074 routinely fails to
complete, causing CI/CD to force kill the container and marking the branch as
failed.
This same problem with test074 has manifested in environments outside of the
CI/CD system, such as the launchpad PPA service.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9481
Issue ID: 9481
Summary: servers/slapd/proxyp.c does not respect --disable-ipv6
and fails to compile
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: ---
current git master, commit: a44706f64 2021-02-26 | ITS#7508 - fix website build
...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9480
Issue ID: 9480
Summary: Update default slapd.conf and slapd.ldif to include
back-monitor
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Now that back-monitor is always built into the slapd binary, we should update
the default slapd.conf and slapd.ldif files so it's present.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9453
Issue ID: 9453
Summary: Move argon2 overlay out of contrib
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: ---
The argon2 module should be moved out of contrib and into mainline OpenLDAP.
Additionally, configure options needs to be added to test for the presence of
libsodium or libargon2 if the argon2 module is to be built
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9446
Issue ID: 9446
Summary: back_passwd: invalid parsing of gecos field
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: ---
Created attachment 788
--> https://bugs.openldap.org/attachment.cgi?id=788&action=edit
fix
Parsing gecos(comment) field of /etc/passwd in
servers/slapd/back-passwd/search.c`pw2entry() has issues. I expands '&':
1) anywhere in in gecos, but the expansion must be limited by user's full name.
2) only 1st '&', but all `&'s in full name must be expanded
(nice explanation:
https://unix.stackexchange.com/questions/535189/ampersand-in-the-passwd-gec…)
fix attached. It expands each `&', left to right, until expanded user's full
name fits into internal { char buf[1024]; }
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.