xattr(7)

💖 xattr — the extended attributes manual, bestie edition 💖

okay so this is from the Miscellaneous Information Manual, it's xattr(7), and no cap it's lowkey one of the most underrated pages in the whole Linux man-pages collection. extended attributes?? they're giving main character energy and nobody talks about them. sit down, hydrate, let's go 🫶

---

✨ NAME ✨

xattr — Extended attributes. that's it, that's the vibe. 💅

---

🌸 SYNOPSIS 🌸

soooo there isn't really a synopsis here bestie, because extended attributes are a concept, not a command. the syscalls that touch them live in their own pages (we'll get to those in SEE ALSO, don't worry, i got you 🎀).

---

🦋 DESCRIPTION 🦋

Extended attributes are these little name:value pairs that are associated permanently with files and directories. think of them like the environment strings a process carries around — same energy, different address space. an attribute can be defined or undefined. and if it is defined, its value can be empty or non-empty. both are valid. we don't judge. ✨

Extended attributes are literally extensions to the normal attributes that every inode in the system already has — you know, the stuff you get from stat(2). people use them to bolt extra functionality onto a filesystem. for example, extra security features like Access Control Lists (ACLs) can be implemented using extended attributes. iconic behavior honestly.

if you have search access to a file or directory, you're allowed to call listxattr(2) and get a list of all the attribute names defined for it. that's it. that's the whole permission gate. 🌈

Extended attributes are accessed as atomic objects, and this part matters. reading (getxattr(2)) retrieves the whole value of an attribute and stores it in a buffer — no partial peeking. writing (setxattr(2)) replaces any previous value with the new one. no merge, no patch, full swap. periodt. 💅

also, the space consumed by extended attributes may be counted towards the disk quotas of the file owner and the file group. so like, they're not free, bestie. they're real bytes. 😭

---

🎀 Extended attribute namespaces 🎀

Attribute names are null-terminated strings. and the name is always specified in the fully qualified namespace.attribute form. like, for example:

• user.mime_type
• trusted.md5sum
• system.posix_acl_access
• security.selinux

the namespace mechanism is what defines the different classes of extended attributes. why do different classes exist? several reasons — for example, the permissions and capabilities you need to manipulate extended attributes can be totally different from one namespace to another. they're not all built the same. 🦋

Currently, there are four classes defined: security, system, trusted, and user. and yeah — additional classes may be added in the future, so stay tuned i guess. 👑

---

🔐 Extended security attributes 🔐

The security attribute namespace is used by kernel security modules — like Security Enhanced Linux — and it's also how file capabilities get implemented (peep capabilities(7)). Read and write access permissions for security attributes depend on the policy each security attribute implements through its security module. and when no security module is loaded, the rules go like this:

• all processes have read access to extended security attributes
• write access is limited to processes that have the CAP_SYS_ADMIN capability

that's the whole deal. 🔥

---

⚙️ System extended attributes ⚙️

System extended attributes are what the kernel uses to store system objects — like Access Control Lists. and the read/write access permissions to system attributes depend on the policy implemented for each system attribute by the filesystems in the kernel. so it's per-attribute, per-filesystem policy. very much a "it depends" situation. 💀

---

👑 Trusted extended attributes 👑

Trusted extended attributes are visible and accessible only to processes that have the CAP_SYS_ADMIN capability. nobody else can even see them. 🫣

they exist so that user-space mechanisms — meaning things outside the kernel — can keep information in extended attributes that ordinary processes should not have access to. like a little VIP section for your metadata. ✨

---

🍓 User extended attributes 🍓

User extended attributes can be assigned to files and directories to store arbitrary additional information — the mime type, character set, or encoding of a file, for example. the access permissions for user attributes are defined by the file permission bits:

• read permission is required to retrieve the attribute value
• write permission is required to change it

now here's the part that gets spicy. the file permission bits of regular files and directories are interpreted differently from the file permission bits of special files and symbolic links. for regular files and directories, the bits define access to the file's contents. but for device special files, they define access to the device described by the special file. and the file permissions of symbolic links are not used in access checks at all. 🙈

why does that matter? because those differences would let users consume filesystem resources in a way that disk quotas can't control — specifically for group-writable or world-writable special files and directories. that's a whole exploit-shaped hole, bestie. 😭

For this reason, user extended attributes are allowed only for regular files and directories, and access to user extended attributes is restricted to the owner and to users with appropriate capabilities for directories that have the sticky bit set (peep the chmod(1) manual page if you need the sticky bit explained — it's the t in the mode, iykyk).

---

🧚 Filesystem differences 🧚

the kernel AND the filesystem both get a say in how many and how big extended attributes can be. the VFS-imposed limits on attribute names and values are:

• names: 255 bytes
• values: 64 kB

and the list of attribute names that can be returned is also limited to 64 kB (see BUGS in listxattr(2) — yes it has its own bugs section, go read it).

Some filesystems — like Reiserfs (and, historically, ext2 and ext3) — require the filesystem to be mounted with the user_xattr mount option before user extended attributes will work at all. so if your xattrs are mysteriously missing, check your mount options first. 🙏

In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes must fit inside a single filesystem block. that's 1024, 2048 or 4096 bytes, depending on the block size that was specified when the filesystem was created. yes, all of them together. budget accordingly. 💀

In the Btrfs, XFS, and Reiserfs filesystem implementations, there's no practical limit on the number of extended attributes you can associate with a file — and the algorithms used to store extended attribute information on disk are scalable. we love a glow up. 🔥

In the JFS, XFS, and Reiserfs filesystem implementations, the limit on bytes used in an EA value is the ceiling imposed by the VFS. (remember, 64 kB. 👆)

In the Btrfs filesystem implementation, the total bytes used for the name, the value, and the implementation overhead bytes are limited to the filesystem's nodesize value — 16 kB by default. so btrfs counts everything, not just your data. very thorough of it. 🎀

---

📜 STANDARDS 📜

Extended attributes are not specified in POSIX.1. that's right, they're not POSIX, bestie. but some other systems — for example, the BSDs and Solaris — do provide a similar feature. so it's a vibe that traveled. ✈️

---

💜 NOTES 💜

The filesystems that extended attributes live on might also be used on architectures with a different byte order and machine word size. so please take care to store attribute values in an architecture-independent format. this is not optional-adjacent advice, it's a real "your bytes will look like soup" warning. 🫶

Also: this page was formerly named attr(5). glow-up complete. 💅

ok genuine reminder: the byte order thing is a real footgun. it's giving "works on my machine" energy until it really, really doesn't.

---

🔗 SEE ALSO 🔗

• attr(1)
• getfattr(1)
• setfattr(1)
• getxattr(2)
• FS_IOC_GETFLAGS(2const)
• FS_IOC_SETFLAGS(2const)
• listxattr(2)
• removexattr(2)
• setxattr(2)
• acl(5)
• capabilities(7)
• selinux(8)

---

💖 okay that's the whole page bestie, you ate it 💖

this one's from the Linux man-pages, version 6.20, dated 2026-02-08. go set some xattrs (responsibly, and with the byte order in mind). mwah 🎀🦋✨