inode_owner_or_capable(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… inode_owner_or_capable(9) β€” like, the Kernel API Manual page, bestie

okay so first things first: this is a page from the Kernel API Manual, section 9, and it's about inode_owner_or_capable. yes that's a mouthful, no we're not renaming it. let's go 🫢


✨ NAME ✨

inode_owner_or_capable β€” checks the current task's permissions on an inode, that's literally the whole vibe check πŸ’…


🌸 SYNOPSIS 🌸

bool inode_owner_or_capable (struct mnt_idmap *idmap , const struct
       inode *inode );

it returns a bool, it takes two args, it's giving "small function, big responsibilities" energy. πŸŽ€


πŸ¦‹ ARGUMENTS πŸ¦‹

  • idmap β€” the idmap of the mount the inode was found from. yeah. that thing. πŸ—ΊοΈ
  • inode β€” the inode being checked. the main character of this whole operation, honestly. πŸ‘‘

πŸ’– DESCRIPTION πŸ’–

so this returns true if the current task either has CAP_FOWNER in a namespace with the inode owner uid mapped, or straight-up owns the file. two ways to slay, pick whichever one applies to you. ✨

now here's the part where you gotta pay attention β€” if the inode was found through an idmapped mount, you must pass the idmap of the vfsmount through idmap. and then this function will take care of mapping the inode according to idmap before it checks permissions. it handles all that for you, which is honestly so nice of it. 🧚

on non-idmapped mounts β€” or if you want the permission check to happen on the raw inode β€” just pass nop_mnt_idmap. simple as that, no cap. πŸ“

πŸ”₯ SEE ALSO πŸ”₯

the kernel file ./fs/inode.c and, like, the entire inode friend group β€” this section is long, grab a snack:


okay that's the whole page, you ate that honestly πŸ‘‘πŸ’œ

source/version: ./fs πŸ¦‹ date: October 2026 β€” mwah, see you in the group chat, bye bestie!! πŸŒˆβ­πŸ’…

πŸ“¦ where this page comes from