Linux basics | Extended attributes explained
Extended attributes are incredibly useful when it comes to storing all kinds of metadata related to a file. Even a lot of experienced sysadmins are unaware of the real capabilities we get when understanding extended attributes at their core. This article is going to fix that.
The most widespread uses cases of extended attributes are setting ACLs and storing SELinux file contexts. But few people ever question how that actually works and what else we can do with them. Let’s dive a little deeper and go beyond using getfacl, setfacl and ls -Z on the CLI.
Assume we have a file named important_document owned by user marc and we want another user lisa to be able to read it too. Normal file permissions don’t allow us to do that. We have to use ACLs like so:
setfacl -m u:lisa:r important_document
We can see that lisa has now read permissions on that file by using
getfacl important_document
owner: marc
# group: marc
user::rw-
user:lisa:r--
group::r--
mask::r--
other::r--
As we already know ACLs are stored within extended attributes, so lets check that out. We list all the extended attributes of a file with
getfattr -d -m - important_document
# file: important_document
system.posix_acl_access=0sAgAAAAEABgD/////AgAEAOoDAAAEAAQA/////xAABAD/////IAAEAP////8=
The important thing here to notice is not our ACL itself (we have setfacl to decode it) but the structure we see here which is `${NAMESPACE}.${KEY}=${VALUE}
Extended attributes are divided into 4 namespaces: user, security, trust and system. Namespaces are also known as classes as they describe the class of the attribute.
Within each namespace we can have multiple key/value pairs. The size and the amount are limited by the filesystem we use.
Security
The security namespace is used to store security related attributes like file contexts for SELinux or capabilities (check out http://www.it-automation.com/2021/07/10/docker-basics-linux-capabilities.html). Write access to that namespace is limited to processes with the CAP_SYS_ADMIN capability. You may want to check getfattr -dm - /usr/bin/ping.
System
The system namespace is mainly used for ACLs like we have seen before. Unlike in the security namespace marc can write here (see http://www.it-automation.com/2021/05/29/discretionary-access-control.html).
Trusted namespace
The trusted namespace is similar to the security namespace except that it is intended for user space. Note that user space refers to user mode/kernel mode and does not mean the file owner can edit those attributes. Like with security attributes access is limited to processes with the CAP_SYS_ADMIN capability. As of today I am not aware of any application that makes use of the trusted namespace.
User
The user namespace is intended for aritrary metadata that we can define on our own.
Let’s try to set a tag key within that namespace:
setfattr -n user.tag -v important important_document
Read that attribute:
getfattr -n user.tag important_document
A couple of years ago I wrote a backup script with rsync. It had to include SELinux file contexts in the backup and always ran into errors when trying to do that. It turned out that the problem was that the target system didn’t have SELinux enabled. Once I understood what was going on the solution was very simple. Using the --fake-super option with rsync makes it transform security attributes into user attributes on the target system and vice versa.
The user namespace gives us flexibility for a wide variety of use cases. What about storing things like ticket numbers, authors, customer numbers, deadlines, tags or whatever comes into you mind.
If you want to read more about extended attributes simply check out
man 7 xattr
