v0.2.0
process-exec cwd: now works, and the grant engine moves onto the shared (sigil grant) algebra
Two changes ship together. process-exec with cwd: has never worked in any released version of sigil-system, and it was not failing quietly: it raised, and it leaked an orphaned process into the caller's directory on the way. Separately, the grant engine is now a profile over (sigil grant) in the standard library rather than a parallel implementation, which is why this release requires sigil 0.21.0 and why it is a minor rather than a patch.
The public API is unchanged. make-grants, grant-allow-all, grants?, grants-principal, grant-add!, grant-check, grant-assert! and grant-decisions keep their signatures and their behaviour.
Changes
process-execwithcwd:runs the child in that directory. Previously it raisedwith-current-directory: expected thunk to satisfy procedure?, and because the spawn was evaluated before the raise, the child had already started. Every such call left an orphaned process, running in the CALLER's directory rather than the requested one.
- The grant engine is now a profile over
(sigil grant). The component-safe path prefix, the argv[0]-exact exec match and the rule thatexec:fullis not downgraded by a later allowlist are now properties of the shared algebra rather than rules this package reimplements. Path canonicalisation stays here, because the algebra is pure and has no filesystem.
- Grants now serialize and reload without changing what they permit. That is what the narrowing below buys, and it holds by construction rather than by testing.
Known regressions
The module now refuses two things it previously accepted. Both are narrow, both fail closed, and both are the price of the serialization guarantee: a resource the spec grammar cannot carry unambiguously is refused when the grant is built, so a grant cannot round-trip into something broader than it started as.
- An exec command containing a comma is refused. The comma separates commands in
exec:allowlist:, so a command name containing one could not survive a round trip. No real command name contains a comma, and this was never expressible through theSLATE_NODE_GRANTSenvironment variable in any case, since that surface splits on commas before the engine sees the string.
- The empty command is no longer granted.
exec:allowlist:git,used to produce an allowlist entry of""alongsidegit. Nothing could ever match it, since argv[0] is never the empty string, so this removes authority that was unreachable.
Filesystem paths are unaffected and may still contain commas and colons. fs:rw:/home/u/Music/Artist, The works and round-trips.
Upgrade notes
This release requires sigil 0.21.0 or later, because (sigil grant) ships in that release. Consumers pinning ^0.1 will not pick this up automatically, which is deliberate: adopting it means adopting the newer toolchain, and that should be a decision rather than a surprise.
CHECK YOUR EXEC ALLOWLISTS FOR A STRAY TRAILING COMMA. During development of this release, exec:allowlist:git, briefly became a hard refusal, which a caller that wraps grant-add! in a guard turns into silently dropping the whole grant. That shape is handled correctly in what shipped: blank entries are dropped and git is still granted. It is worth knowing the shape was ever in play if you are reading your own configuration for the first time in a while.
If you worked around the cwd: bug with an env --chdir or cd ... && wrapper, you can drop it now, and it is worth doing rather than leaving in place. A wrapper of that shape is caller-visible argv, so permitting it through an exec allowlist also permits the wrapper as a command a caller can request, and env runs anything. Passing cwd: directly keeps the caller's allowlist meaning what it says.
If you guarded the raise and carried on, check for orphaned processes. Every cwd: call was leaking one.
The commit this tag names.