From b78288640d8c13cc0fb3f4ee7c82f3efac33940f Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Fri, 4 Sep 2026 17:29:24 +0200 Subject: feat: opt-in Windows service mode (boot-time, one elevation) + v1.0.0 The per-user Startup-folder launcher (W3) only ever runs after this user signs in. A real Windows Service would start earlier, but under LocalSystem/NetworkService -- accounts with no normal profile, so %LOCALAPPDATA%\meshbay\ (config, keystore, data) would not exist for it. Relocating storage to make that work is real surgery, deliberately not done here. Instead: a Scheduled Task, created once with admin rights, that runs AS THIS USER at boot without needing them to sign in first. `schtasks /create ... /ru /rp ""` with no `/it` registers an S4U (Service For User) logon -- no password stored anywhere, and unlike LocalSystem it loads this account's own profile, so config_dir()/ data_dir() need zero changes. The cost: S4U carries no network credential, which the node never needed -- everything it touches is local disk plus outbound internet. Creating the task needs admin (a boot trigger touches system-wide scheduler state, the same reason /sc onlogon needed it); querying/starting/stopping an existing one does not -- Task Scheduler grants the owning user that much itself, which is what lets the Node page's Start/Stop/Restart drive it with no further UAC prompts. meshbay_node/platform.py service_install/_remove/_status/_run/_end -- mirrors autostart_* but for the Scheduled Task; TASK_NAME moved here (was decorative before) meshbay_node/daemon.py new `service install|remove|start|stop|status` verb; restart-daemon and reset now check for the service task too packaging/win/service.ps1 the installer-side equivalent (extraResource); status/run/end never self-elevate -- only install/remove do, exactly matching what Task Scheduler itself requires packaging/win/service-mode.ps1 ONE elevated helper running service.ps1 + firewall.ps1 together, so choosing service mode costs exactly one UAC prompt, not two build/installer.nsh the install-time choice: "run as a background service?" (one elevation, both jobs) vs the existing per-user + separate firewall question. Checked first, unelevated, so re-running setup with everything already configured asks nothing. Uninstall offers the matching one-elevation cleanup, default No. src/main.js winServiceTaskStatus/Run/End, wired into node:installed, node:service-status/-stop/-restart and node:start: when the Scheduled Task exists, drive it; otherwise fall back to the existing per-user spawn/kill path. This is the hard requirement -- Start/Stop/Restart from the Node page must work in either mode. node-page.js / locales a hint explaining why the per-user autostart toggle is absent when service mode is active (info.mode from the backend, no new field to gate on -- it just isn't sent in that case) package.json: 0.1.0 -> 1.0.0. Verified: electron-builder compiles the new NSIS choice logic and ships all three scripts; service.ps1's S4U install fails cleanly (Access denied) when run unelevated, and its status/run/end never touch "runas". Cannot verify the elevated success path myself (no admin in this session) -- that needs a real UAC click. Node suite 843 pass / 25 skip; test_packaging_win.py pins the one-elevation property, the S4U flags, and that main.js actually checks the service task in all three handlers. Co-Authored-By: Claude Sonnet 5 --- packages/meshbay-client/build/installer.nsh | 92 +++++++++++++++++++---------- packages/meshbay-client/package.json | 10 +++- packages/meshbay-client/src/main.js | 87 +++++++++++++++++++++++---- 3 files changed, 145 insertions(+), 44 deletions(-) (limited to 'packages/meshbay-client') diff --git a/packages/meshbay-client/build/installer.nsh b/packages/meshbay-client/build/installer.nsh index d2307c8..70858c6 100644 --- a/packages/meshbay-client/build/installer.nsh +++ b/packages/meshbay-client/build/installer.nsh @@ -1,16 +1,28 @@ ; electron-builder NSIS customisation (auto-included: build/installer.nsh). ; -; Per-user install, no elevation (package.json build.nsis). This does three -; things beyond the default: put the bundled daemon on the user's PATH so -; `meshbay-node` works in a terminal; offer to add the inbound firewall rules -; in one elevated step instead of two "Allow access" dialogs later; and clean -; up the one piece of state that lives outside the install directory (the W3 -; "run at sign-in" launcher). +; Per-user install, no elevation (package.json build.nsis) -- that part never +; changes. What this adds, all conditional on interactive setup (never +; ${Silent}): +; - the bundled daemon dir on the user's PATH, so `meshbay-node` works in a +; terminal; +; - a choice of autostart: the normal per-user Startup-folder launcher (no +; admin, starts at sign-in -- see meshbay_node.platform._startup_vbs), +; or a background-service mode (one admin confirmation, starts at boot, +; no sign-in required -- see meshbay_node.platform.service_install and +; packaging/win/service.ps1); +; - the inbound firewall rules, folded into that SAME elevation when service +; mode is chosen, or offered on their own otherwise -- never two UAC +; prompts for one install; +; - cleanup of whichever of those is outside $INSTDIR on the way out (the +; Startup .vbs; the scheduled task and firewall rules, together, if the +; user opts in). ; ; Deliberately NOT touched: ; - %LOCALAPPDATA%\meshbay\ (node.toml, keystore.enc, unlock.key, data/) -- ; the keystore must survive an uninstall/reinstall; installers place files, -; never remove secrets. +; never remove secrets. This is also why service mode needs no code +; changes to platform.py: it runs as this same user (S4U), so it is the +; same profile either way. !include "WinMessages.nsh" !include "WordFunc.nsh" @@ -40,27 +52,42 @@ WriteRegExpandStr HKCU "Environment" "Path" "$1" SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000 - ; Firewall. MeshBay.exe / meshbay-node.exe (WebRTC) and MeshBay.exe again - ; (LAN cast) each need an inbound allow, and Windows prompts "Allow access" - ; the first time each does. A per-user installer cannot pre-create a - ; firewall rule (that needs admin), so offer one elevated helper: one UAC - ; prompt instead of up to four dialogs spread across first use. - ; - ; Checked first, UNELEVATED (Get-NetFirewallRule needs no admin, only - ; New/Remove do) -- so re-running setup with the rules already in place - ; asks nothing and never pops UAC again. - nsExec::Exec '"${MB_PWSH}" -NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" check' - Pop $0 - ${If} $0 != 0 - ${IfNot} ${Silent} + ${IfNot} ${Silent} + ; Already configured -- an upgrade, or a repair install -- asks nothing. + ; Checked unelevated: reading firewall rules needs no admin, only + ; creating them does (same reasoning as the service task below). Whether + ; service mode or per-user mode was chosen last time, firewall rules + ; existing already means there is nothing left for this dialog to do. + nsExec::Exec '"${MB_PWSH}" -NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" check' + Pop $0 + ${If} $0 == 0 + Goto mb_mode_done + ${EndIf} + + ; The choice. Service mode needs admin to CREATE (a boot trigger touches + ; system-wide scheduler state -- the same reason /sc onlogon needed it + ; too); day-to-day start/stop from the Node page does not, once the task + ; exists, because Task Scheduler grants the owning user that much itself. + MessageBox MB_YESNO|MB_ICONQUESTION \ + "Run MeshBay Node as a background service?$\n$\nIt starts automatically at boot, even before you sign in, and needs one administrator confirmation now (which also sets up the Windows Firewall rules, in the same step).$\n$\nChoose No for the normal per-user mode instead: it starts when you sign in, no admin needed, and you will be asked about the firewall rules separately." \ + IDNO mb_peruser_mode + + ; -- Service mode: one elevation, both jobs -------------------------- + ExecShellWait "runas" "${MB_PWSH}" \ + '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\service-mode.ps1" -Action install' \ + SW_HIDE + Goto mb_mode_done + + mb_peruser_mode: + ; -- Per-user mode: the firewall question stands on its own ---------- MessageBox MB_YESNO|MB_ICONQUESTION \ "Allow MeshBay through Windows Firewall now?$\n$\nMeshBay connects to other devices on your local network. Choosing Yes adds the rules in one step (Windows will ask for administrator confirmation). Choosing No is fine too -- Windows will ask you to allow access the first time MeshBay connects." \ - /SD IDYES IDNO mb_skip_fw + /SD IDYES IDNO mb_mode_done ExecShellWait "runas" "${MB_PWSH}" \ '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" add' \ SW_HIDE - mb_skip_fw: - ${EndIf} + + mb_mode_done: ${EndIf} !macroend @@ -73,18 +100,21 @@ WriteRegExpandStr HKCU "Environment" "Path" "$1" SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000 - ; Offer to take the firewall rules back out (needs admin again). A stale - ; allow-rule pointing at a deleted exe is inert, so this is opt-in and - ; default-No -- a silent uninstall skips it entirely. customUnInstall runs - ; before the files are removed, so firewall.ps1 is still there. + ; Offer to take the firewall rules, and the service task if one was set up, + ; back out together (needs admin again -- one prompt for both, same as + ; install). Both underlying removes are no-ops when there is nothing to + ; remove, so this is safe to run unconditionally regardless of which mode + ; was chosen. Stale rules/tasks are inert if left, so this is opt-in and + ; default-No; a silent uninstall skips it entirely. customUnInstall runs + ; before the files are removed, so service-mode.ps1 is still there. ${IfNot} ${Silent} MessageBox MB_YESNO|MB_ICONQUESTION \ - "Remove MeshBay's Windows Firewall rules? This needs one administrator confirmation. They are harmless if left." \ - /SD IDNO IDNO mb_keep_fw + "Remove MeshBay's Windows Firewall rules and its boot-time service task, if you set one up? This needs one administrator confirmation. Both are harmless if left." \ + /SD IDNO IDNO mb_keep_privileged ExecShellWait "runas" "${MB_PWSH}" \ - '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\firewall.ps1" remove' \ + '-NoProfile -ExecutionPolicy Bypass -File "$INSTDIR\resources\service-mode.ps1" -Action remove' \ SW_HIDE - mb_keep_fw: + mb_keep_privileged: ${EndIf} ; meshbay_node.platform._startup_vbs() -- if the user ran "meshbay-node diff --git a/packages/meshbay-client/package.json b/packages/meshbay-client/package.json index 7f5afcb..55b2dcf 100644 --- a/packages/meshbay-client/package.json +++ b/packages/meshbay-client/package.json @@ -1,6 +1,6 @@ { "name": "meshbay-client", - "version": "0.1.0", + "version": "1.0.0", "description": "MeshBay desktop client — the interface ships with the application, not from the hub", "license": "AGPL-3.0-or-later", "author": "MeshBay Team ", @@ -37,6 +37,14 @@ { "from": "../../packaging/win/firewall.ps1", "to": "firewall.ps1" + }, + { + "from": "../../packaging/win/service.ps1", + "to": "service.ps1" + }, + { + "from": "../../packaging/win/service-mode.ps1", + "to": "service-mode.ps1" } ] }, diff --git a/packages/meshbay-client/src/main.js b/packages/meshbay-client/src/main.js index b0505a9..15c3cc0 100644 --- a/packages/meshbay-client/src/main.js +++ b/packages/meshbay-client/src/main.js @@ -850,6 +850,38 @@ function registerBridge() { }); } + // ── Windows: the opt-in Scheduled Task "service mode" ────────────────────── + // Set up once, elevated, at install time (build/installer.nsh + packaging/win + // /service.ps1 + /service-mode.ps1) or via `meshbay-node service install` + // from an elevated prompt — this process never creates or deletes it, only + // queries and drives an existing one, which needs no elevation (Task + // Scheduler grants the owning user that much itself). Kept in step with + // meshbay_node.platform.TASK_NAME / service_status(). + const WIN_SERVICE_TASK = 'MeshBay Node'; + + function winServiceTaskStatus() { + return new Promise((resolve) => { + execFile('schtasks', ['/query', '/tn', WIN_SERVICE_TASK, '/fo', 'list'], + (err, stdout) => { + if (err) return resolve({ installed: false, state: '' }); + const m = (stdout || '').split(/\r?\n/).find((l) => /^status:/i.test(l.trim())); + resolve({ installed: true, state: m ? m.split(':')[1].trim() : '' }); + }); + }); + } + + function winServiceTaskRun() { + return new Promise((resolve) => { + execFile('schtasks', ['/run', '/tn', WIN_SERVICE_TASK], () => resolve()); + }); + } + + function winServiceTaskEnd() { + return new Promise((resolve) => { + execFile('schtasks', ['/end', '/tn', WIN_SERVICE_TASK], () => resolve()); + }); + } + async function spawnNodeDetached() { const bin = await findNodeBinary(); if (!bin) throw new Error('meshbay-node not found on PATH'); @@ -875,8 +907,12 @@ function registerBridge() { ipcMain.handle('node:installed', async () => { if (process.platform === 'win32') { - const bin = await findNodeBinary(); - return { installed: Boolean(bin), autostart: winAutostartInstalled() }; + const [bin, svc] = await Promise.all([findNodeBinary(), winServiceTaskStatus()]); + return { + installed: Boolean(bin), + autostart: winAutostartInstalled(), + service: svc.installed, + }; } if (process.platform !== 'linux') return { installed: false }; const unit = await new Promise((resolve) => { @@ -897,16 +933,29 @@ function registerBridge() { // looping — exactly the states this panel exists to show and act on. ipcMain.handle('node:service-status', async () => { if (process.platform === 'win32') { - // No Task Scheduler to ask "is it running" — probe the daemon itself. - // `installed` used to be winAutostartInstalled(), which is wrong: it - // answers "does the Startup launcher exist", not "is there a daemon to - // manage". The Node page's Stop/Restart buttons are gated on - // `installed`, so with no autostart configured they silently vanished - // — the daemon was perfectly manageable, just not launchable at - // sign-in. `autostart` carries that state as its own field instead. + const svc = await winServiceTaskStatus(); + if (svc.installed) { + // Service mode: Task Scheduler already tracks running/not, directly — + // no need to probe the daemon's own API for this panel. + const running = /running/i.test(svc.state); + return { + supported: true, + mode: 'service', + installed: true, + activeState: running ? 'active' : 'inactive', + subState: svc.state, + }; + } + // Per-user Startup mode. `installed` used to be winAutostartInstalled(), + // which is wrong: it answers "does the Startup launcher exist", not "is + // there a daemon to manage". The Node page's Stop/Restart buttons are + // gated on `installed`, so with no autostart configured they silently + // vanished — the daemon was perfectly manageable, just not launchable + // at sign-in. `autostart` carries that state as its own field instead. const [p, bin] = await Promise.all([probeNode(), findNodeBinary()]); return { supported: true, + mode: 'startup', installed: Boolean(bin), autostart: winAutostartInstalled(), activeState: p ? 'active' : 'inactive', @@ -939,7 +988,10 @@ function registerBridge() { ipcMain.handle('node:service-stop', async () => { if (process.platform === 'win32') { - await killNodeProcesses(); // hard kill — no CTRL_CLOSE handler yet + const svc = await winServiceTaskStatus(); + if (svc.installed) await winServiceTaskEnd(); + await killNodeProcesses(); // hard kill — no CTRL_CLOSE handler yet; + // also the belt-and-suspenders in case /end left the process running return { stopped: true }; } if (process.platform !== 'linux') { @@ -957,8 +1009,14 @@ function registerBridge() { ipcMain.handle('node:service-restart', async () => { if (process.platform === 'win32') { + const svc = await winServiceTaskStatus(); + if (svc.installed) await winServiceTaskEnd(); await killNodeProcesses(); - await spawnNodeDetached(); + if (svc.installed) { + await winServiceTaskRun(); + } else { + await spawnNodeDetached(); + } const p = await waitForNode(Date.now() + 30000); if (!p) throw new Error('node did not come back up within 30s'); return { restarted: true, ...p }; @@ -1064,7 +1122,12 @@ function registerBridge() { if (process.platform === 'win32') { if (opts && opts.hubUrl && opts.username) provisionNode(opts.hubUrl, opts.username); await killNodeProcesses(); // clear a crash-looping one - await spawnNodeDetached(); + const svc = await winServiceTaskStatus(); + if (svc.installed) { + await winServiceTaskRun(); + } else { + await spawnNodeDetached(); + } const p = await waitForNode(Date.now() + 60000); if (!p) throw new Error('the node did not start within 60s — run it from a ' + 'terminal (`meshbay-node`) to see why'); -- cgit v1.2.3