STRUCT LANDLOCK_DOMAIN(9)

💖 struct landlock_domain(9) 💖

okay bestie so we're in the Kernel API Manual today and the main character is literally struct landlock_domain — it's the Immutable Landlock domain ✨ no cap, that's the whole vibe of the NAME section and I'm obsessed 🫶

---

🌸 SYNOPSIS 🌸

like, here's the whole glow-up, exactly as it is, don't touch it:

struct landlock_domain {
    struct landlock_rules rules;
    struct landlock_hierarchy *hierarchy;
    union {
      struct work_struct work_free;
      struct {
        refcount_t usage;
        u32 num_layers;
        struct access_masks handled_masks[];
      };
    };
 };

---

🎀 Members 🎀

okay so let's meet the cast, one by one, they all ate 💅

• rules — the red-black tree storage for rules. that's it, that's the whole thing, a whole red-black tree just chilling in there holding your rules 🌳
• hierarchy — enables hierarchy identification even when a parent domain vanishes 👻 this is literally needed for the ptrace and scope restrictions, so like, it's not just decorative, it's doing actual work 🫶
• {unnamed_union} — anonymous 🫥 (yes that's the entire description, we love a mysterious icon)
• work_free — enables freeing a domain within a lockless section 🔓 this is only used by landlock_put_domain_deferred when usage reaches zero. and when that happens, the fields usage, num_layers and handled_masks are then unused 💀 like they just sit there, unemployed, not invited to the party 🙈
• {unnamed_struct} — anonymous 🫥 again, mysterious queen
• usage — the number of credentials referencing this domain 👑 like a little fan counter
• num_layers — the number of layers that are used in this domain. this is what lets you check that all the layers allow an access request ✅ (all of them, bestie, no skipping)
• handled_masks — contains the subset of filesystem and network actions that are restricted by a domain 💅 a domain saves all layers of merged rulesets in a stack (FAM), starting from the first layer to the last one. these layers are used when merging rulesets, for user space backward compatibility (i.e. future-proof), and to properly handle merged rulesets without overlapping access rights. these layers are set once and never changed for the lifetime of the domain 🧚 periodt, they're immutable

okay important side note, bestie, don't skip this one: it's not annotated with __counted_by(num_layers) because clang miscomputes the counter address for a FAM nested in an anonymous struct within a union, which trips FORTIFY: https://github.com/llvm/llvm-project/pull/228309 — so yeah, that's a real thing, don't "helpfully" add it back 😭

---

🦋 Description 🦋

a domain is created from a ruleset by landlock_merge_ruleset and enforced on a task 🎯 once it's created, its rules and access masks are immutable — like, no edits, no take-backs, it's giving set in stone ✨

and unlike struct landlock_ruleset, a domain has no lock field 🚫🔒 which lowkey makes sense given the whole immutable thing, main character energy fr fr

---

🌈 SEE ALSO 🌈

• Kernel file ./security/landlock/domain.h
• struct landlock_details(9)
• struct landlock_hierarchy(9)
• landlock_union_access_masks(9)

go read those next, iykyk 🍓

---

and that's the whole page bestie!! 💜 this icon lives over in ./security/landlock and the version stamp is from October 2026, and the title card says struct landlock_domain(9) — okay bye, hydrate and go read your kernel headers 🧚‍♀️💖⭐