fix: keep the VNC display across a running-origin restore; refuse the CNI case up front - #37
Merged
Merged
Conversation
… CNI case up front The .79 round showed a user-mode VM losing VNC after `restore --force`: the relaunch read the display the stop tail had just cleared. The display is the VM's persisted configuration; only the password and the proxy are launch-scoped, and a non-CNI VM has no proxy to stop. A CNI VM with VNC cannot relaunch without its password (launch already refused after the disks were reverted), so restore now refuses it before touching anything. (cherry picked from commit 0617aca)
…play The guard keyed on CNI, but a user, tap or bridge VM can be started with --vnc-password too, and the password is never persisted: its relaunch came back unauthenticated. The record now carries a non-secret vnc_password_set bit written at launch and cleared at stop, and restore refuses any running origin whose display is password-gated. Linux test drives the refusal against the fake qemu and checks it never terminates.
A start that daemonized qemu and then failed to read the pidfile or save the record left a live, later-adopted qemu with the bit still false, so a restore could relaunch it unauthenticated. The bit is now written with the record before the spawn; a save failure aborts the launch.
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
1 participant
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.
Follow-up to #36, found by running it against a real sequoia:15 guest on bare metal.
With
--net user,vm restore --forceon a running VM relaunched qemu without-vnc: the stop tail had cleared VNCDisp before launch read it, so the display was lost after every running-origin restore, while the pre-#36 binary kept it. The display is the VM's persisted configuration; only the password and the proxy are launch-scoped, and a non-CNI VM has no proxy to stop.vnc_password_setbit, written at launch and cleared at stop;Netnsstays as the fallback for records written before the bit existed. The error names the working sequence (stop, restore,start --vnc N --vnc-password).saveStoppedis gone; Stop keeps its own tail. launch still stops a stale proxy before every relaunch.TestRestoreRefusesRunningPasswordedVNCdrives the refusal against the fake qemu.Hardware evidence (
.79, sequoia:15): pre-#36 binary answers RFB on the display afterrestore --forcein user mode; the #36 build does not (qemu alive, no-vnc); this branch answers RFB after restore in user mode, refuses the running CNI origin with the display untouched, and stop/restore/start --vnc --vnc-passwordrelaunches exactly one proxy.Gates:
make lint0 issues both GOOS,make fmt-check,asl ./...both GOOS,go test -race ./...; the Linux-gated test run on the Linux host.