feat: offer 'enclave vnc-viewer' - #29
Conversation
Opt-in `vnc` mixin: a virtual X display (Xvnc) running a fullscreened Chromium, served over VNC (RFB). The raw RFB port is published on the host loopback so any VNC client can attach directly. Find the port with `enclave ps --json` and read the per-session password from /tmp/enclave-vnc/vnc-password. A supervisor keeps Xvnc, matchbox-window-manager, and a headful Chromium at $VNC_URL alive with restart loops. Xvnc listens on all container interfaces so the published port reaches it, and enforces a random password at the RFB layer (VncAuth). That password is what shapes the boundary: holding it is what grants control of the display, and because it is generated per session it reaches exactly one session's display, which is why the agent knowing it is harmless. Exporting DISPLAY and BROWSER=vnc-open routes "open in browser" flows onto the contained display, where all real browsing stays on the session's gateway-restricted network.
|
I will rework this command to be named |
Resolves the current project's VNC-enabled session, its published RFB binding, and its per-session password, then launches a host viewer. The default is xtigervncviewer on Linux and macOS Screen Sharing via open, overridable with the vnc_viewer config key. The command and the config key name the protocol rather than the generic "GUI": a viewer has to speak VNC to be usable here, and "GUI" reads as if it were a UI for enclave itself. The password reaches the viewer through the environment (VNC_PASSWORD, ENCLAVE_VNC_PASSWORD) rather than argv, which /proc would expose to every local user for the viewer's lifetime. TigerVNC reads VNC_PASSWORD itself, so the default viewer needs no placeholder and nothing is written to disk. vnc_viewer is a registry option without a CLI flag. It configures a host command, so a one-shot override on the command line would just be the command the user could run directly.
|
Yes, I'd be in favor of that in general: make sure enclave(-core) provides all the generic extensibility needed and let extensions mature outside and decide later. The maturity bar can be much lower in the enclave-extensions. Of course the vnc viewer is a bit of a special case because it is a great generic feature, but still it might be easier to just move it to the extensions and have it merged asap. |
|
It is a great feature that unlocks a ton of use cases for enclave users, so it is a really hard decision. But in the end, I agree with Philip, as the extension path will make it available and visible faster to users. |
What it does
Resolves the current project's VNC-enabled session, its published RFB
binding, and its per-session password, then launches a host viewer. The
default is
xtigervncvieweron Linux and macOS Screen Sharing via open,overridable with the
vnc_viewerconfig key.The password reaches the viewer through the environment (
VNC_PASSWORD,ENCLAVE_VNC_PASSWORD) rather than argv, which /proc would expose toevery local user for the viewer's lifetime. TigerVNC reads
VNC_PASSWORDitself, so the default viewer needs no placeholder and nothing is
written to disk.
gui_vieweris a registry option without a CLI flag. It configures a hostcommand, so a one-shot override on the command line would just be the
command the user could run directly.
Based on #24
How to test
xtigervncviewerif you don't have it already.sudo apt install tigervnc-viewer./bin/enclave --features +vnc./bin/enclave vnc-viewerFollow-ups
Breaking changes
Review checklist