Bug Fixes
lager box config applyno longer reports success while applying nothing.applyrunsstart_box.shon the box as the login user, and its four box-config renderers create files in/etc/lager(box_config.docker.sh,user_requirements.txt,cargo_packages.txt,npm_packages.txt). Creating a file needs write permission on the directory, andlager installleft/etc/lagerowned by the container user only (33:33, mode755) — so every render failed withEACCES. Renders are soft-failed by design (the container must always come up), which turned this into a silent no-op: the install steps read files that were never written, soapplyskipped them, stamped the applied-hash, and printed “Applied box config”. Everypip/cargo/npmpackage, mount, volume, and env var added throughlager box configwas quietly dropped on any box whose last provisioning step was an install./etc/lageris now owned33:<box-user-group>mode2775(setgid), so the container (owner) andstart_box.sh(group) can both write it./etc/lageris no longer world-writable.lager updatepreviously granted the box user write access by runningchmod 777on the directory, which also gave it to every other local account — enough to replacebox_config.json,saved_nets.json, or the org secrets. It now gets the same owner/group/setgid treatment as above: what the two writers actually need, and nothing more.- A box-config render failure is now loud, and no longer poisons the retry. A failed render used to print a one-line warning and a raw Python traceback, then let the run continue as if applied. It now reports which file could not be written, why, and how to fix it;
start_box.shexits 3 (“container up, config NOT applied”) andapplyno longer stamps the applied-hash (which had sealed the bug shut on retry) or rolls back a healthy container.