[RFC PATCH 2/9] Refactor per-layer information in rulesets and rules

[Tingmao Wang]

On 3/8/25 18:57, Mickaël Salaün wrote:
[...]
> Yes, we could put the access rights in the hierarchy, but that would
> involve walking through the hierarchy to know if Landlock should
> actually handle (i.e. allow or potentially deny) an access request.
> Landlock is designed in a way that makes legitimate/allowed access as
> fast as possible (there is still room for improvement though).  In the
> case of the supervisor feature, it should mainly be used to dynamically
> allow access which are statically denied for one layer.  And because it
> will require a round trip to user space anyway, the performance impact
> of putting the supervisor pointer in landlock_hierarchy is negligible.
> 
> Initially the purpose of landlock_hierarchy was to be able to compare
> domains (for ptrace and later scope restrictions), whereas the
> landlock_ruleset is to store immutable data (without references) when
> used as a domain.  With the audit feature, the landlock_hierarchy will
> also contain domain's shared/mutable states and pointers that should
> only be rarely accessed (i.e. only for denials).  So, in a nutshell
> landlock_ruleset as a domain should stay minimal and improve data
> locality to speed up allowed access requests.

That makes total sense - I will move the supervisor pointer to 
landlock_hierarchy and drop this change in the next version.