Today let’s take look at file attributes. Whereas, permissions and ACL’s deal with user and group access to a file, attributes are properties of a file that regulate how the operating system interacts with a given file.
There are 15 file attributes: append only (a), no atime updates (A), compressed (c), no copy on write (C), no dump (d), synchronous directory updates (D), extent format (e), immutable (i), data journalling (j), project hierarchy (P), secure deletion (s), synchronous updates (S), no tail-merging (t), top of directory hierarchy (T), and undeletable (u).
Even though there are 15 attributes it’s been my experience that (i) immutable, and (a) append only attributes seem to be the only ones that work consistently across filesystems. If you are using an ext2, ext3, or ext4 filesystem then c,s, and u will not be honored by your filesystems. The secure delete (s), and undeletable (u) attributes would definitely be a nice-to-have feature in the future. If you are using btrfs (likely on a SUSE or OpenSUSE based system) then (c) compression will be respected along with a few others (feel free to experiment).
The only attribute flag that I want to look at today is (i) immutable. The reason I have singled this attribute out is to demonstrate the power you have with this flag, and because it’s the only one I use on any regular basis.
List attributes with lsattr
Let’s make a file and add some content to it:
luke@Tumbleweed01:~/Documents> touch file1 luke@Tumbleweed01:~/Documents> echo "Some awesome file content" >> file1 luke@Tumbleweed01:~/Documents> cat file1 Some awesome file content luke@Tumbleweed01:~/Documents>
What attributes does this file have upon creation?
luke@Tumbleweed01:~/Documents> lsattr file1 ------------------- file1 luke@Tumbleweed01:~/Documents>
You will notice that newly created files have no attributes (at least if you are using OpenSUSE with btrfs like I am).
If you are using Ubuntu you will very likely see the “e” flag which means that your file system is using extents for mapping the file to disk.
Making a file immutable with chattr
What does it mean to make a file “immutable”?
Immutable means that the file cannot be changed in any way. You can’t delete it, you can’t add new data, or remove old data, or even change its name. When you add the (i) attribute you have chiseled the file into stone. Not even root can change a file that has been marked immutable (at least not without removing the flag first).
Attribute flags can be added and removed with sudo using the
chattr command with +/- and the attribute.
sudo chattr +i file1
Now try to add another line to this file.
luke@Tumbleweed01:~/Documents> echo "Even more awesome content" >> file1 bash: file1: Operation not permitted luke@Tumbleweed01:~/Documents>
What about as root? Still not permitted right?
Can you delete it?
luke@Tumbleweed01:~/Documents> rm file1 rm: cannot remove 'file1': Operation not permitted luke@Tumbleweed01:~/Documents> sudo rm file1 rm: cannot remove 'file1': Operation not permitted luke@Tumbleweed01:~/Documents>
Notice the message output “Operation not permitted” even when using sudo.
Our POSIX permissions have not changed if you check:
luke@Tumbleweed01:~/Documents> ls -l file1 -rw-r--r-- 1 luke users 26 Feb 21 10:49 file1
You can see that my user should have read and write access to this file. The file attribute tells the filesystem that the contents of this file are frozen and cannot change.
Remove the immutable flag by replacing +i with -i:
luke@Tumbleweed01:~/Documents> sudo chattr -i file1
What is the use case for this?
I see using these attributes as only a single layer to defend files that I want to protect against accidental deletion or to prevent them from being altered.
For example, I use a media server called Plex to stream photos and movies to other devices in my home. I use the immutable flag to prevent files from being accidentally deleted or maliciously deleted in the event that the wrong person was to gain access to my Plex server.
File attributes should be seen as a way to further layer your file access scheme, and not as a replacement for best practices.