Extended Attributes

From Segfault
Jump to: navigation, search

From the bestbits.at (Archive) site:

Extended attributes are arbitrary name/value pairs which are associated with files 
or directories. They can be used to store system objects like capabilities of 
executables and access control lists, as well as user objects.

Extended Attributes (EA) are implemented differently on each operating system. This article tries to give a short overview and some usage examples for various operating systems. In most implementations, EAs follow the same schema "namespace:attribute:value".

FreeBSD

FreeBSD supports EAs on UFS and ZFS. For ZFS, extended attributes can be enabled on a per-filesystem basis.

Only root can query the system namespace:

Note that adding EAs to a file might take up some space if the EA does not fit into the file's inode space:[1]

$ stat -f "File: %N Size: %z Blocks: %b" test.txt
File: test.txt Size: 25170 Blocks: 56

$ setextattr user sha256 `sha256 -q test.txt` test.txt
$ stat -f "File: %N Size: %z Blocks: %b" test.txt
File: test.txt Size: 25170 Blocks: 64

Linux

Linux supports EAs on many (but not all) filesystems:

  • ext2, ext3, reiserfs - when mounted with user_xattr
  • ext4[2], btrfs, jfs, xfs

Note that adding EAs to a file might take up some space if the EA does not fit into the file's inode space:[1]

$ stat -c "File: %n Size: %s Blocks: %b" test.txt
File: test.txt Size: 25170 Blocks: 56

$ setfattr -n user.sha512 -v "`sha512sum test.txt`" test.txt
$ stat -c "File: %n Size: %s Blocks: %b" test.txt
File: test.txt Size: 25170 Blocks: 64
  • The system namespace is reserved for the system administrator and/or the kernel.
  • The user namespace is reserved for general usage. That is, to store arbitrary combinations of attribute and value to a filesystem object.
  • The security.selinux namespace is reserved for SELinux attributes.

MacOS X

In MacOS X, EAs are managed by xattr(1), a Python script apparently:

$ xattr -l test.txt
bar: 4242
foo: 42

Print only a specific attribute:

$ xattr -p foo test.txt
42

We can also use plain old ls(1) to display EAs and the size of their values:

$ ls -l test.txt
-rw-------@ 1 dummy  dummy  1024 Apr  9 12:49 test.txt

$ ls -l@ test.txt
-rw-------@ 1 dummy  dummy  1024 Apr  9 12:49 test.txt
      bar        4
      foo        2

Let's change a value, add another attribute, and delete an attribute:

$ xattr -w foo 23 test.txt
$ xattr -w baz 10 test.txt
$ xattr -d bar test.txt

$ xattr -l test.txt
baz: 10
foo: 23

MacOS can store incredibly long amounts of EA information without the file taking more space:

$ stat -f "File: %N Size: %z Blocks: %b" test.txt
File: test.txt Size: 1024 Blocks: 8

$ seq 1 131100 | while read a; do
     echo "a: $a"
     xattr -w foo "`seq $a | while read f; do printf x; done`" test.txt || break
done
[...]
a: 131070
a: 131071
a: 131072
a: 131073
xattr: [Errno 7] Argument list too long: 'test.txt'
$ stat -f "File: %N Size: %z Blocks: %b" test.txt
File: test.txt Size: 1024 Blocks: 8

But we have ~128K of EA material stored:

$ xattr -l test.txt > test.ea
$ ls -lgo test.ea
-rw-------  1   131078 Apr  9 13:35 test.ea

So where does MacOS X store this EA?[3] In a resource fork, apparently:

$ mv test.txt /mnt/smb/data/tmp/

Now, on that Samba server, we can see how the resource fork is stored in a separate file on this non-HFS+ filesystem:

% ls -lgo test.txt ._test.txt
-rw------- 1 135168 Apr  9 13:40 ._test.txt
-rwx------ 1   1024 Apr  9 13:40 test.txt

Solaris

Solaris supports EAs on UFS[4], NFS[5], TMPFS[6] and ZFS[7] (but can be disabled by mounting with noxattr). Sadly, its usage[8] is rather cryptic: