RFE: opt-in non-inheriting path_beneath rule (exact-inode match)

[magodo]

Add a per-rule flag — tentatively LANDLOCK_RULE_PATH — to landlock_add_rule so a path_beneath rule applies only when the access targets the exact inode the rule was created from, not when it targets a descendant.

Current behavior

Within a single ruleset layer, when the kernel evaluates an access on path F, it walks from F up the filesystem hierarchy and uses the first rule it encounters; that rule's allowed access bits determine whether the layer permits the access. In effect:

A layer grants access to F if any rule on F or any ancestor of F grants it.

This is what makes a directory rule recursive: granting RW on /a covers everything under /a.

Proposed behavior (opt-in, per rule)

A rule created with the new flag would not propagate down the hierarchy. The layer would grant access to F only if a rule exists on F itself with the matching bits. Existing rules without the flag keep today's recursive semantics.

A layer grants access to F if a non-inheriting rule on F grants it, or any inheriting rule on F or an ancestor of F grants it.

(Layer composition across stacked rulesets is unchanged — still intersection.)

Motivation / use case

Building user-facing sandboxes (interactive agents, file-scoped tools) that prompt the user to grant access incrementally. A common pattern is "grant this directory so the tool can work inside it" — but today that necessarily exposes every sensitive nested path (~/.ssh, ~/.aws, ~/.gnupg, browser profile dirs, ...). The sandbox author currently has no way to express "grant this directory, but require a separate explicit grant for each subdirectory the tool wants to descend into."

Concrete example: an agent is granted access to /home/user/projects/. With current semantics, that immediately covers /home/user/projects/secrets/, /home/user/projects/.envrc, etc. With a non-inheriting rule on /home/user/projects/, listing the directory and touching files directly in it would work, but descending into projects/secrets/ would trigger a separate denial → re-prompt → narrower grant.

[l0kod]

One challenge with this feature would be to safely deal with the ability to rename a child directory, which could be an issue for the next run of the sandbox, see #28.

Building user-facing sandboxes (interactive agents, file-scoped tools) that prompt the user to grant access incrementally.

I'm not sure this feature would help here. It looks like users will be prompted much more because they will need to explicitly grant access to every child directories/files.

The good practice is to have clear separate file hierarchies per access. That's why Island create different workspaces per sandboxes.

[RazeLighter777]

Hi @magodo I've been working on a very similar feature in #28 for several months, it is only different from this in that the flag on the rule prevents inheritance of access grants from ancestors, rather than preventing propagation below a the flagged rule.

Doing it that way makes it easier to use.

Let's say you want to grant write access to ~, but exclude .ssh, .aws, .gnupg.

So in this proposal, you put a tagged rule on ~, allowing write, but it doesn't propagate. This proposal here would still require granting access to all of the other directories under ~, requiring listing them all at runtime and adding rules for each. This also wouldn't handle creation of new subdirectories, since the access right wouldn't propagate from ~ (ie whitelisting approach). In constrast, doing it as proposed in #28 allows you to put the non inheritance on only the sensitive directories (blacklisting), which is easier to manage.

Indeed as noted by @l0kod, any proposal for this must prevent sandbox-restart attacks wherein a sensitive path could be renamed/reparented/linked to/from a directory under the sandbox, restart under the same policy, and gain access to the files because they are now on an unrestricted path. This is the tricky part, and the most complex part of the feature.