fix(docker): remove libtcnative-1 at runtime when FIPS mode is detected

[dsilvam]

Summary

Fixes the JVM crash (SIGSEGV in libcrypto.so.3 EVP_MD_get0_provider+0x4) that occurs when running dotCMS on FIPS-enabled hosts (e.g. RHEL with CIS Level 2 hardening).

The fix shipped in PR #34213 (SSLEngine=off) was insufficient. Setting SSLEngine=off only prevents OpenSSL from being used for SSL connections, but libtcnative-1 still loads libcrypto.so.3 and calls OpenSSL for non-SSL operations (e.g. random number generation). On a FIPS-enabled kernel without the OpenSSL FIPS provider (fips.so, not shipped in Ubuntu 24.04), this triggers the same crash regardless of the SSL engine setting.

This PR extends 15-detect-fips-and-set-ssl-engine.sh to also remove libtcnative-1.so at container startup when FIPS mode is detected, before Tomcat starts. Tomcat then falls back to pure Java NIO/JSSE automatically. libtcnative-1 remains installed in the image by default for all non-FIPS environments — no performance impact for the majority of installations.

Changes

• 15-detect-fips-and-set-ssl-engine.sh: when FIPS_ENABLED=true, remove libtcnative-1.so.0* before Tomcat starts, in addition to setting CMS_SSL_ENGINE=off
• Added comment explaining why SSLEngine=off alone is not sufficient

Test plan

• Start container on a non-FIPS host — libtcnative-1 must still load and CMS_SSL_ENGINE=on (no regression)
• Start container on a FIPS-enabled host (/proc/sys/crypto/fips_enabled=1) — container must start without SIGSEGV, log must show [FIPS Detection] Removing libtcnative-1 to prevent OpenSSL initialization in FIPS mode
• Verify CMS_DISABLE_APR_SSL=true path still works on non-FIPS host
• Verify CMS_SSL_ENGINE=off manual override still works

Related

Closes #34212
Related: #34067, PR #34213, Freshdesk ticket #34489

[claude]

Claude finished @dsilvam's task in 2m 22s —— View job

---

Code Review

• Read changed script (15-detect-fips-and-set-ssl-engine.sh)
• Check Dockerfile / entrypoint context (user, paths, set -e)
• Verify server.xml shape (single-line listener) and ownership chain
• Sanity-check the approach vs. wezell's permission concern

Summary

The pivot from rm libtcnative-1.so (root-only) to sed-editing server.xml is the right call — /srv is chowned to dotcms:dotcms in the Dockerfile (lines 20–21, 27), so the non-root container user can rewrite server.xml without the chown a+w workaround wezell suggested. Idempotent on restart, falls back to JSSE cleanly, and the only listener in server.xml matching the pattern is the single-line AprLifecycleListener on line 27, so sed '/AprLifecycleListener/d' is safe today.

A few things worth a second look:

Findings

1. PR description and test plan are stale (medium)

The description still says "remove libtcnative-1.so.0* before Tomcat starts" and the expected log line in the test plan is Removing libtcnative-1 to prevent OpenSSL initialization in FIPS mode. The actual implementation removes the AprLifecycleListener from server.xml and logs AprLifecycleListener removed from server.xml — libtcnative-1 will not be loaded. Anyone running the test plan verbatim will look for the wrong log line. Please update the description and the verification log strings.

2. set -e makes the WARNING branch unreachable (low)

entrypoint.sh:3 sets set -e, and 15-detect-fips-and-set-ssl-engine.sh is sourced (line 17), so set -e is in effect inside it. If sed -i fails for any reason (e.g. server.xml mounted read-only from a ConfigMap), the entrypoint aborts on that line — the if ! grep -q ... "Failed to remove" warning branch is never reached. Not a correctness bug (failing fast is arguably better than crashing later with SIGSEGV), but the code reads as if it expects to continue and warn. Either drop the warning branch as dead code, or guard the sed: sed -i ... || true then rely on grep verification.

3. Brittle sed pattern (low)

sed -i '/AprLifecycleListener/d' deletes any line containing that substring. Fine for the current server.xml, but if a future change ever splits the <Listener> tag across multiple lines (or adds a comment mentioning it), this silently leaves dangling/malformed XML. A more defensive pattern would scope to the actual element, e.g. sed -i '/<Listener[^>]*AprLifecycleListener[^>]*\/>/d' — still single-line-only, but at least it won't eat a stray comment. Not blocking, but worth a note.

4. Volume override case (informational)

If a user mounts a custom server.xml (e.g. via Kubernetes ConfigMap, typically read-only), the script will abort under set -e on FIPS hosts. That's probably the right behavior, but it's a behavior change for that deployment shape and may surprise someone. Worth mentioning in release notes if FIPS-customer overlap with ConfigMap-mounted server.xml is non-zero.

Not issues (verified)

• Permissions: /srv is owned by dotcms:dotcms (Dockerfile L20–21), server.xml is reached through the tomcat symlink (L27) into the chowned tree → write succeeds as UID 65001. wezell's concern doesn't apply with this approach.
• Idempotency: sourced on every container start, second run is a no-op since the line is already gone; grep still confirms success.
• TOMCAT_HOME default matches entrypoint.sh:7 (/srv/dotserver/tomcat).
• No other AprLifecycleListener occurrences in server.xml to worry about.
  • fix/34212-fips-remove-libtcnative-on-fips-host

[wezell]

Isn't this going to be a permissions issue? The dotcms container runs as dotcms:dotcms uid:65001 and not root.

You might need to chown a+w /usr/lib/x86_64-linux-gnu/libtcnative-1.so.0 in the docker build to get this to work.