[PATCH v3 1/5] landlock: Implement LANDLOCK_ADD_RULE_NO_INHERIT

Tingmao Wang m at maowtm.org
Sat Dec 6 17:07:54 UTC 2025


On 12/6/25 15:26, Justin Suess wrote:
> Thank you for the review.
>
> I agree with the bind mount limitations for this flag. I think it's
> reasonable to expect the sandboxer to provide protections for pre-
> existing bind mounts as opposed to the kernel.
>
> This limitation is a tradeoff between safety and complexity.
>
> I looked into doing in automatically, and it ends up being sort of a
> mess, and you end up having to iterate through the bind mounts, and I
> suspect it would be a major performance hit, especially if we have to
> account for changes outside the sandbox after the policy is already
> enforced.
>
> We can note this limitation in the docs.
>
>> On 11/26/25 12:20, Justin Suess wrote:
>>> Implements a flag to prevent access grant inheritance within the filesys
> tem hierarchy

Minor nit but please try not to wrap lines this way, as when the text is
colored / indented by quote level, it makes it seem like you're adding a
reply.

> [...]
>>> @@ -1232,6 +1656,121 @@ static bool collect_domain_accesses(
>>>  	return ret;
>>>  }
>>>
>>> +/**
>>> + * collect_topology_sealed_layers - collect layers sealed against topol
> ogy changes
>>> + * @domain: Ruleset to consult.
>>> + * @dentry: Starting dentry for the upward walk.
>>> + * @override_layers: Optional out parameter filled with layers that are
>>> + *                   present on ancestors but considered overrides (not
>>> + *                   sealing the topology for descendants).
>>> + *
>>> + * Walk upwards from @dentry and return a mask of layers where either t
> he
>>> + * visited dentry contains a no_inherit rule or ancestors were previous
> ly
>>> + * marked as having a descendant with no_inherit.  @override_layers, if
>  not
>>> + * NULL, is filled with layers that would normally be overridden by mor
> e
>>> + * specific descendant rules.
>>> + *
>>> + * Returns a layer mask where set bits indicate layers that are "sealed
> "
>>> + * (topology changes like rename/rmdir are denied) for the subtree root
> ed at
>>> + * @dentry.
>>> + *
>>> + * Useful for LANDLOCK_ADD_RULE_NO_INHERIT parent directory enforcement
>  to ensure
>>> + * that topology changes do not violate the no_inherit constraints.
>>> + */
>>> +static layer_mask_t
>>> +collect_topology_sealed_layers(const struct landlock_ruleset *const dom
> ain,
>>> +			       struct dentry *dentry,
>>> +			       layer_mask_t *const override_layers)
>>> +{
>>> +	struct dentry *cursor, *parent;
>>> +	bool include_descendants = true;
>>> +	layer_mask_t sealed_layers = 0;
>>> +
>>> +	if (override_layers)
>>> +		*override_layers = 0;
>>> +
>>> +	if (!domain || !dentry || d_is_negative(dentry))
>>> +		return 0;
>>> +
>>> +	cursor = dget(dentry);
>>> +	while (cursor) {
>>> +		const struct landlock_rule *rule;
>>> +		u32 layer_index;
>>> +
>>> +		rule = find_rule(domain, cursor);
>>> +		if (rule) {
>>> +			for (layer_index = 0; layer_index < rule->num_layer
> s;
>>> +			     layer_index++) {
>>> +				const struct landlock_layer *layer =
>>> +					&rule->layers[layer_index];
>>> +				const int level = layer->level ? layer->lev
> el :
>>> +								 layer_inde
> x + 1;
>> Wouldn't layer->level always be >= 1 here?  Using layer_index doesn't mak
> e
>> sense since layer_index is just the index that the struct landlock_layer
>> happened to be in that rule's array.
>
> Hmm good catch. I was replicating logic from other places while sometimes not realizing
> exactly why the code is doing what it does and didn't make that realization. Seems to work
> fine and pass after I fixed it in my working tree so it will be in the next version.

Well actually this function would become unused after removing the "Apply
descendant no-inherit masking" code above.

> [...]
>
> Thank you for the review of the patch. Trimming the code was very
> satisfying. I see that the disconnected directory handling was
> simplified in linux-next, which is gonna make things easier but also
> make rebasing require some more careful attention. I assume your next
> patch series for LANDLOCK_ADD_RULE_QUIET is going to be rebased off
> those disconnected directory changes as well.
>
> I'll implement these fixes in my working tree and be ready when you drop
> your next version to do a rebase on top of your series again. If you
> have a base commit SHA you could give me that you are building your next
> patch series version on top of already, that would be helpful.

Will send v6 now, but you can also take it from
https://github.com/micromaomao/linux-dev/tree/landlock-quiet-flag :)



More information about the Linux-security-module-archive mailing list