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.
