fix(tanner): recreate snare state files on start so restarts survive init's chown (#3160) - #3164
Conversation
Strix Security ReviewNo security issues found. Updated for Reviewed by Strix |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
…init's chown (#3160) Root cause: honeypot-init's chown re-arms the ownership trap by changing /opt/snare directory and snare.pid/err/log files to the snare user. DAC_OVERRIDE is deliberately absent from tanner's capabilities, so snare cannot recreate these files once ownership changes. On restart, snare fails to write state files and cannot initialize cleanly. Fix: Add rm -f for snare.pid, snare.err, snare.log in the entrypoint shell before exec'ing snare-entry.sh. This ensures snare creates fresh state files owned by the snare user on every start, surviving the init chown without capability widening. Live verification: restarts=0, HTTP 200, re-armed-trap restart completed cleanly. Closes #3160
8b9e9ba to
05d46d2
Compare
![strix-security[bot]](https://avatars.githubusercontent.com/in/2749804?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the single changed file, arcane/home/honeypot-tanner/compose.yml. The PR updates documentation comments describing the SNARE capability decision and adds one shell command to the snare service entrypoint: rm -f /opt/snare/snare.pid /opt/snare/snare.err /opt/snare/snare.log; before exec /usr/local/bin/snare-entry.sh.
The added command operates on three hardcoded, literal state-file paths with no variable expansion or user-controllable input, so no injection, path traversal, or arbitrary-file-deletion vector is introduced. rm does not follow a symlink on its final path component, and the removal runs before SNARE binds its network port. The change also explicitly avoids widening container capabilities (declining CHOWN/DAC_OVERRIDE), which is security-positive rather than a weakening of existing controls. No authentication, authorization, secret, or cryptographic changes are present. No security issues were found in the changed code.
Reviewed by Strix
Configure security review settings
There was a problem hiding this comment.
Reviewed the single-file change to arcane/home/honeypot-tanner/compose.yml. The PR adds a rm -f of three hardcoded SNARE state file paths before exec'ing snare-entry.sh, with comment updates explaining the root cause. The change introduces no user-controlled input, no injection surface, and no widened privileges — it explicitly avoids adding CAP_DAC_OVERRIDE and preserves the existing capability-drop and no-new-privileges hardening. No security issues found.
Reviewed by Strix
Configure security review settings
1 participant
Summary
SNARE container restarts were failing due to ownership changes on state files (snare.pid/err/log) caused by honeypot-init's chown during stack initialization. The entrypoint now removes these files before exec'ing snare, ensuring fresh creation under the correct ownership.
Root Cause
Prior measurement incorrectly concluded DAC_OVERRIDE and CHOWN capabilities had no effect on snare startup. The actual issue: root without CAP_DAC_OVERRIDE cannot truncate-open an existing file it does not own. Directory mode gates create/unlink but not truncation of owned files. Snare's state files flip ownership each restart (prior run leaves them root:root, then honeypot-init's chown re-owns to nobody), creating EACCES when snare tries to write.
Fix
Entrypoint removes snare.pid/snare.err/snare.log before exec'ing snare-entry.sh, forcing fresh creation without capability widening.
Verification (2026-09-10 CEST)
Closes #3160