fix(linux): stop chmod'ing resolv.conf to 0444 in direct-write path (EACCES crash loop on container restart)

[xz-dev]

Summary

Fixes a restart crash loop in containers: the direct-write fallback in setup_resolv_conf chmod'ed /etc/resolv.conf to 0444 via write_nameserver, which poisons Docker's bind-mounted host-side resolv.conf file. Every subsequent container restart fails with EACCES unless the process holds CAP_DAC_OVERRIDE.

• Remove the fchmod(fd, 0444) from write_nameserver.
• On the direct-write path, if open() fails with EACCES, restore mode 0644 and reopen — heals deployments already poisoned by older versions.

Why the 0444 was wrong

The comment says it protects resolv.conf from NetworkManager, but NM runs as root with CAP_DAC_OVERRIDE and can overwrite a 0444 file anyway. The real protection on the mount path is the MS_REMOUNT|MS_RDONLY remount, not the file mode. On the direct-write path the chmod protects nothing — it only guarantees the next startup fails.

Failure mechanism (Docker)

1. Fresh docker run: resolv.conf is 0644 root:root (Docker-owned host file, bind-mounted) → tun2proxy opens, writes, chmods to 0444 → healthy.
2. docker restart (also daemon restart / boot restore): same file, still 0444. open(O_WRONLY) → owner has no write bit → needs CAP_DAC_OVERRIDE → cap_drop: ALL containers fail with EACCES → with --exit-on-fatal-error, permanent crash loop. Only docker rm + re-create fixes it.

Observed in production (Docker Engine 29.1.3, ghcr.io/tun2proxy/tun2proxy:v0.8.3): host-side resolv.conf of the tun2proxy container was 444, all other containers on the host were 644.

Log signature:

WARN  tproxy_config::linux] failed to bind mount custom resolv.conf onto /etc/resolv.conf, resorting to direct write
ERROR tproxy_config::linux] tproxy removal failed: Permission denied (os error 13)
ERROR tproxy_config::common] Failed to set up TProxy: EACCES: Permission denied

Testing

Integration test added (test-restart-eacces.sh), run against Docker Engine 29.1.3, container flags --cap-drop ALL --cap-add NET_ADMIN --device /dev/net/tun:

scenario	stock v0.8.3	this PR
fresh create healthy	yes	yes
host resolv.conf mode after first run	0444 (poisoned)	0644 (kept)
docker restart healthy	no (EACCES crash loop)	yes
restart with pre-poisoned 0444 file (upgrades)	n/a	heals to 0644, healthy

cargo check / cargo test pass (crate has no other tests).

Notes

• Downstream tun2proxy consumes this crate via crates.io (tproxy-config = "^7.0.7"); it will need a version bump + release for users on official images.
• I plan to file a matching issue in tun2proxy/tun2proxy linking here.

[xz-dev]

Why fresh creation works but every restart fails (mechanism walkthrough)

Adding a detailed explanation of the failure mode here, since it's the non-obvious part of this bug and the reason it ships silently.

Linux DAC check. The process runs as root (uid 0), and the file is root:root. When uid matches the owner, the kernel checks the owner permission bits. After the first run the file is r--r--r-- (0444), so the owner has no write bit. Open would fail — unless the second check passes: CAP_DAC_OVERRIDE, which bypasses file permission bits entirely. A container with cap_drop: ALL and only NET_ADMIN added does not hold it.

docker run (create path). Docker generates a fresh host-side resolv.conf, mode 0644 root:root, and bind-mounts it into the container as /etc/resolv.conf. tun2proxy takes the direct-write fallback (no CAP_SYS_ADMIN for the bind-mount path), opens the file — the owner write bit is there, the open succeeds — writes its nameserver line, and chmods the file to 0444. Everything is healthy. The poison is now planted, with zero symptoms.

docker restart (restart path). Same container, same host-side file is reused — still 0444. This time open(O_WRONLY | O_TRUNC) fails with EACCES: the owner has no write bit, and there is no CAP_DAC_OVERRIDE to fall back on. Setup fails; with --exit-on-fatal-error the process exits; the restart policy brings it back up; it fails again — permanent crash loop. The only unlock is docker rm + re-create, which makes Docker write a fresh 0644 file.

The trap window. A deployment that only ever creates (first install, image upgrade) never sees the bug. It fires exactly on the restart paths — docker restart, dockerd restart, host reboot restore — i.e. the paths production setups rely on. In our case the stack ran fine for days after first deploy, then the first host reboot took it down.

Bonus: the cleanup path fails too. When setup fails, _tproxy_setup runs _tproxy_remove to roll back. The rollback writes the saved original resolv.conf content back with fs::write — to the same 0444 file, with the same missing capability. That's why the log signature is three lines that look like three separate problems:

WARN  failed to bind mount custom resolv.conf ... resorting to direct write   ← normal in containers, not an error
ERROR tproxy removal failed: Permission denied                                 ← cleanup hits the same 0444
ERROR Failed to set up TProxy: EACCES: Permission denied                       ← the actual failure

Three log lines, one root cause.

Why the fix has two parts:

• Dropping the fchmod(0444) stops new deployments from being poisoned. The chmod is also ineffective for its stated purpose even on hosts: NetworkManager runs as root with CAP_DAC_OVERRIDE and can overwrite a 0444 file anyway; the real protection on the mount path is the MS_REMOUNT|MS_RDONLY remount, which not even root can write through without another remount.
• The EACCES-recovery reopen lets deployments already poisoned by an older version heal themselves on their first restart after upgrading, instead of crash-looping until someone recreates the container. Verified in the integration test: a pre-poisoned 0444 file comes back as 0644 and the container starts healthy.

[Copilot]

Copilot review overview

🟡 Changes recommended

The integration test has portability, recovery-coverage, log-capture, and startup-timeout issues.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Hardcoded Docker root breaks custom and rootless Docker setups · New
• Test never exercises permission healing after upgrade · New

What changed in this PR

Fixes Linux resolv.conf permission poisoning and container restart failures.

Changes:

• Removes the direct-write 0444 chmod.
• Restores 0644 and retries for poisoned files.
• Adds Docker restart integration coverage.

File	Summary
src/​linux.rs	Updates direct-write permissions and recovery handling.
test-restart-eacces.sh	Adds restart and permission validation tests.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ssrlive]

Thanks