Linux - Extended attributes

Extended attributes (xattrs) are a feature in Linux filesystems that allow users and applications to associate additional metadata with files and directories beyond the standard attributes (like file size, owner, permissions, and timestamps).

Think of them as "sticky notes" you can attach to a file. The filesystem stores them, but it doesn't necessarily understand what is written on them—that is up to the applications (or users) that read them.

The Structure: Key-Value Pairs

An extended attribute consists of a name and a value.

• Name: Must be a string in the format namespace.attribute.
• Value: Can be text or binary data (up to a certain size limit, usually 64KB depending on the filesystem).

The Four Namespaces

To prevent chaos (e.g., a user overwriting a security label), xattrs are divided into four specific namespaces. You must specify the namespace when creating an attribute.

A. user

• Purpose: For regular users to store arbitrary data.
• Requirement: The file permissions must allow the user to write to the file.
• Example: You want to tag a file with the URL it was downloaded from, or a checksum.
  • user.download_url = "http://example.com/file.zip"
  • user.mime_type = "text/plain"

B. security

• Purpose: Used by kernel security modules like SELinux and AppArmor.
• Requirement: Only the kernel or processes with CAP_SYS_ADMIN can write these, but they are crucial for system security.
• Example: SELinux uses this to label a file so it knows which processes are allowed to touch it.
  • security.selinux = "unconfined_u:object_r:user_home_t:s0"
  • security.capability (Used to give a binary specific root privileges without making it fully setuid root).

C. system

• Purpose: Used by the kernel for filesystem features, most notably ACLs (Access Control Lists).
• Requirement: generally restricted to kernel use.
• Example: When you use setfacl to give a specific user permission to a file (beyond the standard Owner/Group/Other), Linux stores that permission list here.
  • system.posix_acl_access

D. trusted

• Purpose: Restricted attributes for users with the CAP_SYS_ADMIN capability (root).
• Requirement: Only fully privileged processes can see or edit these.
• Use Case: Often used by userspace filesystems (like GlusterFS or Ceph) to store internal metadata that regular users shouldn't tamper with.

How to Use Them

You manage xattrs using the attr package tools: setfattr and getfattr.

Setting an attribute (setfattr)

To add a comment to a file named report.txt:

# Syntax: setfattr -n [name] -v [value] [file]
setfattr -n user.comment -v "This is the final draft" report.txt

Reading an attribute (getfattr)

To see the attributes attached to a file:

# -d dumps all attributes
getfattr -d report.txt

Output:

# file: report.txt
user.comment="This is the final draft"

Removing an attribute

setfattr -x user.comment report.txt

Is xattrs per-file?

Yes, extended attributes (xattrs) are strictly per-file.

Every individual file, directory, or symbolic link has its own independent set of attributes. They are stored in the filesystem's metadata structures, "next to" the file but separate from the actual file contents (data).

Because they are metadata and not data, they are not automatically preserved if you move the file to a filesystem that doesn't support them (like FAT32 on a USB stick) or use a copy command that isn't aware of them (like standard cp without flags).

Where exactly are they stored?

The physical location depends on which filesystem you are using. The filesystem always tries to keep them close to the file header for speed, but will move them further away if they get too big.

1. ext4 (Most common Linux filesystem)

ext4 uses a "spillover" method.

• Primary Location (In-Inode): Every file has an "inode" (a data structure holding permissions, owner, size, etc.). Standard ext4 inodes are usually 256 bytes, but the standard file info only takes up about half of that. ext4 tries to stuff your xattrs into the unused empty space at the end of the inode.
  • Performance: Extremely fast (zero extra disk seeks).
• Secondary Location (External Block): If your xattrs are too large or too numerous to fit in that small gap, ext4 allocates a single separate 4KB block on the disk to hold them.
  • Performance: Slower (requires an extra jump to read that block).

2. XFS (High performance / Servers)

XFS is designed to handle massive amounts of metadata and uses three "formats" depending on size:

• Local (Shortform): If the attributes are tiny, they are stored literally inside the inode.
• Leaf: If they overflow the inode, they move to a single external memory block.
• Node (B-Tree): If you have thousands of attributes (which XFS allows), it creates a dedicated B-tree index just to manage that single file's attributes.

3. Btrfs (Modern / Copy-on-Write)

Btrfs stores everything in B-trees. Xattrs are stored as Items (XATTR_ITEM) inside the filesystem tree.

• They are physically located in the "leaves" of the tree, usually right next to the file's other metadata (like its filename).
• Limit: Btrfs usually limits the size of an xattr to the "node size" of the filesystem (default is 16KB).

4. NTFS (Windows)

If you are accessing a Windows drive from Linux, these are called ADS (Alternate Data Streams).

• They are stored in the MFT (Master File Table).
• Unlike Linux, which treats them as small metadata tags, NTFS treats them as fully hidden files attached to the main file. They can theoretically be gigabytes in size.

Why does this matter?

• Performance: If you keep your xattrs small (like simple tags or SELinux labels), they stay "in-inode" on ext4/XFS and are read instantly when the file is accessed.
• Corruption: If you delete a file's inode (metadata) but not the data blocks, the xattrs are gone forever, even if you can recover the file contents.

Real-World Limitations

1. Filesystem Support: Most modern filesystems (ext4, XFS, Btrfs, ZFS) support xattrs by default. However, some older filesystems or network protocols (like basic NFS versions) might not support them, or might require specific mount options (e.g., mount -o user_xattr).
2. Copying Files: Standard commands like cp or tar do not always preserve xattrs by default.
   • cp often needs the --preserve=xattr flag (or -a).
   • tar usually needs the --xattrs flag.
   • rsync needs -X.
   • If you forget these flags, you lose the metadata (including potentially critical SELinux labels or ACLs).

Summary

• Standard Attributes: Owner, Group, Permissions, Size, Time.
• Extended Attributes (xattrs): Custom metadata (user.comment), Security labels (security.selinux), and Access Control Lists (system.posix_acl_access).