fix(docker): stop the container entrypoint printing database connection strings in logs#4346
Conversation
…on strings in logs The entrypoint runs under set -x, which echoes each command with variables expanded. The RUN_OPS_DATABASE_URL and RUN_OPS_LEGACY_DIRECT_URL guards and the ClickHouse block referenced full connection strings, so the DSN (with password) was printed to the container logs on every boot. Turn tracing off around those regions and restore it after, leaving migration behavior unchanged.
|
WalkthroughContainer startup now disables shell tracing while evaluating database and ClickHouse migration configuration, preventing credential-bearing connection strings from being logged. Tracing is restored for migration commands, skip messages, Prisma file copying, and server startup. A changelog entry records the webapp fix. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
2 participants
Summary
The container entrypoint runs under
set -x, which echoes every command to the logs with its variables expanded. Several startup guards reference full database connection strings, so the DSN (including the password) was printed to the container logs on every boot. This turns tracing off around those lines so connection strings are never traced, while leaving migration behavior and ordinary startup logging unchanged.Fix
The leaking lines are the
[ -n "$RUN_OPS_DATABASE_URL" ]and[ -n "$RUN_OPS_LEGACY_DIRECT_URL" ]guards, and the ClickHouse block (its[ -n "$CLICKHOUSE_URL" ]guard plus the lines that buildGOOSE_DBSTRINGfromCLICKHOUSE_URL).set -xprints each of these with the credential expanded. Tracing is now disabled around each region and restored afterward, so non-secret tracing is preserved everywhere else. The existing legacy-migration subshell already protected its own command body; this adds the missing protection for the guards and the ClickHouse block.{ set +x; } 2>/dev/null if [ -n "$RUN_OPS_DATABASE_URL" ]; then set -x ...Verification
Built the webapp image and ran it with dummy sentinel connection strings whose password token is
S3NTINEL_PW_DoNotLog, then grepped the boot logs.Before (unmodified), the token appears in the traced guards:
After,
grep S3NTINEL_PW_DoNotLogon the same run returns nothing, and the normal "skipping ... migrations" lines still log.