Harden permissions for persisted secret files - #23465

…s and FIFOs

fopen_secret_write() hard-failed when fchmod() failed, but fchmod() is gated on
ownership, not on write access. A secret left behind by an agent that ran as
root stays writable through the netdata group while being un-chmod-able by the
netdata user, and some filesystems refuse chmod outright. Claiming, claimed_id
persistence and bearer token persistence would then fail permanently where they
used to work. Tolerate the failure when the file is already inaccessible to
group and other, and log a warning; keep failing when it is not.

The secret directories are group-writable (cloud.d is 0770), so the final path
component is attacker-controllable. Add O_NOFOLLOW so a planted symlink is not
chmod-ed and truncated, and fstat()/S_ISREG() plus O_NONBLOCK so a planted FIFO
neither blocks the open nor receives the secret.

Also convert dyncfg_file_save(): dyncfg payloads are user-submitted job
configurations that routinely carry database passwords, SNMP communities and
API tokens, and were landing group-readable under the daemon's umask.

Tests cover the symlink and FIFO refusals, including that the symlink target's
mode and contents are left untouched.

…e write

Refusing to write when fchmod() fails left claiming permanently broken wherever
a secret was left behind by an agent that ran as root: such a file is writable
through the netdata group but cannot be tightened, because fchmod() is gated on
ownership. Verified in docker with a non-root daemon and a pre-existing
0660 root:netdata cloud.conf/claimed_id/private.pem - claiming failed with
"Failed to save claiming info to disk" and "Cannot write private key file".

The secret directories are group-writable (cloud.d is 0770), so when the file is
accessible to group or other and cannot be chmod-ed, unlink it and recreate it
with O_CREAT|O_EXCL at 0600. This is a truncating open, so the old content was
being discarded anyway, and O_EXCL makes a path recreated in between an error
rather than a place to write a secret into. When the unlink is refused the write
still fails, so a secret is never written to a file that could not be made
private. The same scenarios now claim successfully and leave every secret at
0600, owned by the daemon user.

Also drop two hand-rolled copies of this logic now that the helper covers them:
the MCP dev-preview key writer (which deleted the key when fchmod() failed) and
the management API key writer. The latter keeps its mkstemp()+rename() path on
platforms without O_NOFOLLOW, since that is where it gets its symlink safety.

The symlink refusal was guarded by #ifdef O_NOFOLLOW while the helper's contract
promised it unconditionally, so on the Windows build (mingw/UCRT does not define
the flag) open() followed a planted symlink and the fstat() only confirmed that
the symlink's target was a regular file. Every caller was affected.

Check the path explicitly where the flag is missing, the way status-file-io.c
already does: lstat() first and refuse a symlink with ELOOP (the errno
O_NOFOLLOW would have produced) or any other non-regular file with EINVAL; add
O_EXCL when nothing is there, so a path planted between the lstat() and the
open() fails with EEXIST instead of being followed; and compare the opened
inode against what was inspected to catch a swap. The remaining gap - a hardlink
planted before the lstat(), normally blocked by fs.protected_hardlinks - is now
stated in the contract instead of being implied away.

All of it sits in #else / #ifndef blocks, so platforms with O_NOFOLLOW are
unaffected. The management API key writer keeps its own mkstemp()+rename() path
on those platforms, since the atomic rename also closes the hardlink window; the
reason is now recorded there.

…e is refused

Review follow-ups on the secret-write helper:

- When a file is exposed and un-chmod-able and the replacement unlink() also
  fails, report unlink()'s errno instead of the earlier fchmod() one, and log
  both. The unlink error is the actionable one: a secret bind-mounted as a single
  file gives EBUSY (verified), a read-only directory gives EROFS.
- fdopen() before ftruncate(), so a failure there leaves the previous content in
  place like every other refusal in this helper does, instead of leaving an empty
  file behind while reporting failure.
- Honour a "b" in the caller's mode when the platform has O_BINARY: the
  descriptor decides newline translation there, and the PEM writers pass "wb".
- Guard S_ISLNK, which had not been used before in code built for Windows. A
  symlink fails the following S_ISREG() check anyway, so the refusal holds
  either way and only the reported errno differs.
- Correct the documented contract: an already-owner-only file on a chmod-refusing
  filesystem may keep a mode tighter than 0600, and the lstat()/O_EXCL/inode
  fallback closes the symlink redirect but not a hardlink planted before it -
  which is why the management API key writer keeps its own rename() path.

…them

The checks lived only in a standalone EXCLUDE_FROM_ALL target that no workflow
builds, so nothing verified fopen_secret_write() automatically. Move them into
fopen_secret_write_unittest() next to the implementation, where paths_unittest()
runs them - and paths_unittest() is already executed in CI by
`netdata -W unittest` through tests/run-unit-tests.sh.

The standalone target stays as a thin runner for the same function, so the checks
exist in one place instead of being duplicated. Skipped on Windows, where POSIX
mode bits, symlinks and FIFOs do not carry their intended meaning, and the
process umask is saved and restored so the surrounding unittests are unaffected.