get_inode_id(9)

💅 get_inode_id — Kernel API Manual, bestie edition 🎀

okay so real talk, this one is from the Kernel API Manual and it's short but it's mighty, so let's get into it ✨

---

🌸 NAME 🌸

get_inode_id — literally goes and looks up the Landlock object for a dentry 🦋

✨ SYNOPSIS ✨

bool get_inode_id (const struct dentry *const dentry , struct
landlock_id *id );

not me showing you the exact signature because details matter periodt 💅

🎀 ARGUMENTS 🎀

• dentry — the dentry you wanna look up. that's the one, bestie 🫶
• id — gets filled with the inode's Landlock object pointer on success. yes, filled. it's giving "you get the goods on success only" 💖

👑 DESCRIPTION 👑

so here's the tea ☕: this function extracts the Landlock object pointer from dentry's inode security blob and stores it in id, so it can be used as a rule-tree lookup key. that's the whole job. iconic, honestly 🌟

when this returns false — that's a negative dentry or there's no Landlock object — then no rule can match this inode, so landlock_unmask_layers need not be called. no cap, you can skip it 🙈

⚠️ okay but listen: callers that gate landlock_unmask_layers on this function must handle the NULL masks case independently, because the !masks-returns-true early-return in landlock_unmask_layers will not be reached. 😭 like, it just won't get there. see the allowed_parent2 initialization in is_access_to_paths_allowed. lowkey important, don't sleep on it 🔥

🦋 RETURN 🦋

True if a Landlock object exists for dentry, false otherwise. simple as that 💀✨

🌈 SEE ALSO 🌈

• Kernel file ./security/landlock/fs.c — yes, the file itself is in the see-also, we love a self-referential moment 💜
• is_masked_device_ioctl(9)
• is_access_to_paths_allowed(9)
• collect_domain_accesses(9)
• current_check_refer_path(9)
• unmask_scoped_access(9)
• get_required_file_open_access(9)

go read all of them, iykyk 👑

---

sending you off with love from ./security/landlock, October 2026 — that's the source/version and the date, bestie, mwah 💋 🧚💖