logs: refuse symlinks when opening the log file (O_NOFOLLOW) - #323

Summary

Add O_NOFOLLOW to the open() call in logFile() so that nsjail does not silently follow a symlink at the user-supplied --log / log_file path.

Defect

logs.cc:logFile() opens the log file with O_CREAT | O_RDWR | O_APPEND | O_CLOEXEC but no O_NOFOLLOW. If an attacker can pre-plant a symlink at the log path (race condition in /tmp, shared tmp dir, predictable path), nsjail follows the symlink and appends log lines to the symlink target via O_APPEND. The existing PLOG_W warning is logged but the write still happens against the target file.

Repro (before fix)

$ touch /tmp/target
$ ln -s /tmp/target /tmp/log
$ nsjail -l /tmp/log -- /usr/bin/true
$ cat /tmp/target    # log lines appended to /tmp/target

Repro (after fix)

$ nsjail -l /tmp/log -- /usr/bin/true
[W] logFile(): Couldn't open('/tmp/log'): Too many levels of symbolic links
$ cat /tmp/target    # unchanged

Runtime-verified on nsjail HEAD (f100fd9) on 6-core Linux.

Fix

-		    open(log_file.c_str(), O_CREAT | O_RDWR | O_APPEND | O_CLOEXEC, 0640));
+		    open(log_file.c_str(), O_CREAT | O_RDWR | O_APPEND | O_CLOEXEC | O_NOFOLLOW,
+			0640));

2 insertions, 1 deletion. logs.cc only. Matches the O_NOFOLLOW convention used elsewhere in nsjail (createDirRecursively in util.cc) and in runc / Docker / systemd-nspawn for log and cgroup file writes.

Impact

Defense-in-depth hardening. Not a vulnerability in the strict sense, but a missing standard hardening that matches the convention used by every major container runtime for log / state file writes. The same util::writeBufToFile function is used at the cgroup write sites; this PR addresses the log file path only (the cgroup paths are a follow-up).

Notes

• The PR is intentionally narrow: one file, one line, no behavior change for valid operator use cases.
• This is a follow-up to PRs mnt: mount the auto-provisioned /proc nosuid,nodev,noexec #283, mnt: apply per-mount nosuid/nodev/noexec recursively to recursive binds #284, sandbox: fail loudly when seccomp_unotify is requested but unusable #285 (already merged 2026-08-26), which closed similar silent-downgrade / missing-standard-hardening gaps.