posix_acl_from_xattr(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… posix_acl_from_xattr β€” the Kernel API Manual, bestie edition ✨

okay so this is posix_acl_from_xattr(9) from the Kernel API Manual and it is literally the glow-up station for POSIX ACLs. it takes them from backing-store format and turns them into VFS format. no cap, it's giving translator-at-the-border energy πŸ›‚βœ¨


🌸 NAME 🌸

posix_acl_from_xattr β€” convert POSIX ACLs from backing store to VFS format. that's the whole job. she does one thing and she does it iconically πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

struct posix_acl * posix_acl_from_xattr (struct user_namespace *userns ,
       const void *value , size_t size );

like, look at her. three args, returns a pointer to a struct posix_acl. main character signature fr fr 🫢


πŸ¦‹ ARGUMENTS πŸ¦‹

  • userns β€” the filesystem's idmapping. yes bestie, this is the whole reason she exists, hold that thought 🧚
  • value β€” the uapi representation of POSIX ACLs. the raw material, the before-photo πŸ“Έ
  • size β€” the size of void. that's what the manpage says, we don't question it, we just nod πŸ’€

⭐ DESCRIPTION ⭐

so picture this: your filesystem stores POSIX ACLs in the unaltered uapi format. honestly? valid. but the VFS wants struct posix_acl, and those are two different vibes entirely. that's where our girl comes in πŸ”₯

if you're a filesystem keeping POSIX ACLs around in unaltered uapi format, you should use posix_acl_from_xattr when you read them from the backing store and convert them into the struct posix_acl VFS format. she's specially designed for this, like specifically intended to be called from the acl inode operation. not a general-purpose helper, she has a lane and she stays in it πŸ‘‘

and here's the cute part: posix_acl_from_xattr will map the raw {g,u}id values stored in ACL_{GROUP,USER} entries into idmapping in userns. so all those raw numeric ids get their little passport stamped and come out speaking the right language 🌈

⚠️ okay important heads-up, no skipping: posix_acl_from_xattr does not take idmapped mounts into account. and honestly that's on purpose, let her explain. if it did, then calling it from the get acl inode operation would return POSIX ACLs mapped according to an idmapped mount, which would mean that the value couldn't be cached for the filesystem. caching rights revoked. tragedy. 😭 so instead, idmapped mounts are taken into account on the fly during permission checking, or right at the VFS–userspace boundary before reporting them to the user. clean, correct, iconic ✨

πŸ’– RETURN πŸ’–

what you get back, in order of slay:

  • Allocated struct posix_acl on success β€” the dream scenario, the moment πŸ’…
  • NULL for a valid header but without actual POSIX ACL entries β€” valid but empty, she's there but she's not there πŸ™ˆ
  • or an ERR_PTR encoded error code β€” the vibe check failed, check your pointers bestie πŸ’€

πŸ” SEE ALSO πŸ”

Kernel file ./fs/posix_acl.c, plus the whole friend group, they all ate:


🫢 that's the whole page! this one lives out of ./fs, dated October 2026 β€” big kiss to the kernel docs, mwah πŸ’‹ go convert some ACLs, you've got this πŸ’œ
πŸ“¦ where this page comes from