fix(agent): drop baked dbus machine-id so regen yields a fresh id#7
Merged
Conversation
Contributor
Author
|
Hardened per review (thanks — the original swallowed non-
|
…sh id regenMachineID truncated /etc/machine-id, but systemd-machine-id-setup's source order falls back to a baked-in regular-file /var/lib/dbus/machine-id and re-adopts the old id. dropStaleDBusMachineID removes that copy first; a symlink into /etc/machine-id or a missing file is left alone, and any other lstat error is surfaced so regen fails loudly instead of silently reusing the old id. CRNG reseed was never affected.
Contributor
Author
|
Ran the full /code + /simplify + tighten pass (was skipped before — thanks for catching):
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Found during cocoon clone-reseed e2e:
cocoon vm reseed --machine-id(and clone auto-reseed) reported success and/etc/machine-id's mtime changed, but the content was the same id.regenMachineIDtruncates/etc/machine-id, thensystemd-machine-id-setupruns — and its documented source order falls back to/var/lib/dbus/machine-id. Images that bake that as a regular file (not a symlink to/etc/machine-id) make setup re-adopt the stale id. Result: clones keep the source's machine-id, defeating the whole point of regen.The CRNG entropy/reseed ioctls — the security-critical mechanism — were never affected; this is only the machine-id half.
Fix
Before running
systemd-machine-id-setup, remove/var/lib/dbus/machine-idiff it's a regular file (Lstat+Mode().IsRegular()— a symlink into/etc/machine-idis correct and left untouched). setup then has no stale source to fall back to and generates a fresh id; dbus recreates its copy from the new/etc/machine-idon next start.Verification
lint 0 issues × {linux,darwin,windows}, tests green. End-to-end machine-id-actually-rotates verification lands when this ships as v0.1.7 and gets baked into an os-image (chicken-and-egg with the guest agent version); the root cause is precisely the systemd source-order fallback, which this removes.