Overriding filesystem allow and deny

[bodograumann]

I thought I read this information in the docs before, but cannot find it right now:

How much overriding of file-system permissions is possible? I.e.

• allow access to /home/bodo/A, but
• deny access to /home/bodo/A/B, but
• allow access to /home/bodo/A/B/C, but
• deny access to /home/bodo/A/B/C/D, but
• allow some tool calls to access /home/bodo/A/B/C/D/E?

Btw, the scheme here seems outdated: https://nono.sh/docs/cli/internals/capability-manifest

[SequeI]

Hi Bodo!

It's platform dependent considering we use Landlock(Linux) and Seatbelt(macOS) consisting of their own primitive semantics and specifications. I'll try outline both below

• Linux (Landlock): strictly allow-list, and it fails closed rather than mis-enforcing. Landlock has no way to carve a deny out of an allowed subtree; allow and deny aren't layered rules evaluated in order, there's just a set of allowed paths. So if your config expresses allow A → deny A/B → allow A/B/C → deny A/B/C/D, nono doesn't quietly grant the whole thing as if the denies weren't there. Instead, validate_deny_overlaps detects that a deny.access path (A/B, A/B/C/D) sits underneath an allowed parent (A) and fails sandbox startup outright with a Landlock deny-overlap error. Nothing runs.

• macOS (Seatbelt): Deny can override allow, because Seatbelt evaluates rules with last-match-wins ordering. So allow A → deny A/B → allow A/B/C → deny A/B/C/D is mechanically achievable if the profile emits the rules in the right order. But this multi-level alternation isn't exposed as a general user-facing feature

TLDR: macOS is a lot more permissible with what your configuration shows above, Linux would fail with a hard error upon startup!

We have glob pattern matching incoming in the next release, which will make profile configuration a lot better imo for scenarios like yours too. ( #1580)