cap_inode_removexattr(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… cap_inode_removexattr β€” the manual page bestie

okay so bestie, this is a Kernel API Manual page for cap_inode_removexattr(9), and no cap it's lowkey iconic β€” it's the little gatekeeper that decides whether an extended attribute is allowed to get yeeted off an inode. ✨


✨ NAME ✨

cap_inode_removexattr β€” literally the function that determines whether an xattr may be removed. that's it, that's the whole vibe check. πŸŽ€


🌸 SYNOPSIS 🌸

int cap_inode_removexattr (struct mnt_idmap *idmap , struct dentry *dentry , const char *name );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • idmap β€” the idmap of the mount the inode was found from. yes it's a whole parameter, don't skip it πŸ’…
  • dentry β€” the inode/dentry being altered. this is the main character, the thing we're messing with 🫢
  • name β€” the name of the xattr to be changed. like, which one, bestie? be specific 🌸

πŸ”₯ DESCRIPTION πŸ”₯

So what it do: it determines whether an xattr may be removed from an inode, returning 0 if permission is granted, and -ve if it's denied. that's the whole deal β€” 0 means slay, negative means absolutely not. 😭

Now the important bit, and honestly this is giving very careful: if the inode has been found through an idmapped mount, the idmap of the vfsmount must be passed through idmap. This function will then take care to map the inode according to idmap before checking permissions. ✨

on non-idmapped mounts, or if the permission checking is to be performed on the raw inode, just simply pass nop_mnt_idmap. easy. no stress. πŸ’–

And why do we even care? This is used to make sure security xattrs don't get removed by those who aren't privileged to remove them. it's giving bodyguard energy fr fr β€” the unprivileged do NOT get to touch the security xattrs, periodt. πŸ‘‘


πŸ’œ SEE ALSO πŸ’œ

Kernel file ./security/commoncap.c β€” and here's the whole friend group, every single one, no gatekeeping:


that's the page bestie, you ate it up πŸ’…βœ¨ and real quick, the cute lil sign-off credits: this one lives in ./security and it's dated October 2026. mwah πŸŽ€πŸ¦‹πŸ’–

πŸ“¦ where this page comes from