Linux file attributes explained
Linux filesystems such as ext4, xfs and btrfs support file attributes that are incredibly useful in many cases. This article will show what file attributes are and give some examples on how to use them to your advantage.
Linux has all sorts of permission checks on files. Everyone is aware of permissions bits. Also special permissions and ACLs are widely known. A much less known feature are file attributes. Even some experienced sysadmins don’t even know they exist.
Linux file attributes are implemented as “inode flags—attributes” (see man 2 ioctl_iflags if you are interested in a more detailed explanation.). They are somewhat under the hood because neither the ls nor the stat command shows them. Also they are not a feature of Linux itself but of the filesystem we are using. So when choosing a filesystem this should be a one of the selection criterias.
File attributes help us to fine tune the behaviour of a file in different ways. Let’s check the file attributes within our home directory with
lsattr ~
The output looks similar to the bitmask we know from file permissions. We can get the full name of set attributes with
lsattr -l ~
File attributes are useful in all kind of scenarios whether it is performance, security or auditability. For a detailed explanation of each attribute see the chattr man page
man 1 chattr
Here are some scenarios where they are useful.
Performance
Think of a webserver that serves millions of static html pages. If it has a high load we will want to tune its performance so it can serve as many requests as possible. However whenever it reads one of the html pages our system updates the atime record of that file and that induces a lot of I/O. A simple way to get away with that is the noatime mount option. The downside of that is that it disables it for all files at once. The a attribute gives us more control by disabling atime updates for specific files rather than for the whole partition.
Security
One of the basic ideas of Linux security is the least privilege principle. Every user (which can be a normal user as well as a system user) should have only those privileges that are necessary to do their work. A couple of years ago I had to secure an outdated container that wouldn’t get any security upgrades anymore. Upgrading the application on that container would have incurred a lot of cost and for those who were responsible for the application update security was not an argument for that investment.
In terms of security that was an unacceptable state but it fueled my creativity. I made the container immutable by setting the immutable (i) attribute to all files in the container except those that the application needed to write to. As the container did not have the CAP_LINUX_IMMUTABLE capability even the root user within the container was not allowed to delete that flag.
Auditability
One of the beneftis of IT Automation is auditability. However that requires nobody does undocumented ad hoc changes anymore. Even if we agree on with everyone on our team people it doesn’t keep people from doing it over and over again. It looks like we don’t have enough discipline to stick to what we promised. Think about smoking. Everyone knows it is unhealthy and most of the smokers have promised themselves to stop it. So how is it that there are 1 billion smokers around the world? Because they have access to cigarettes everywhere. If they had to pick their own tobacco they probably wouldn’t do it.
It is perfectly the same with ad hoc changes. It is the opportunity that tricks us. The aforementioned I wrote for security works for IT Automation as well. Permissions like the immutable attribute, undeletable attribute or the append only attribute help us to protect our systems from ad hoc changes and may enforce that we do things properly with Infrastructure as Code.
File attributes are incredibly easy to use but to make them really useful we have to use our creativity.
Even the simplest tools can empower people to do great things - Biz Stone
