Working with files in Linux - File Attributes
In the previous two posts, we’ve looked at file permissions and access control lists.
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
file system then c
,s
, and u
will not be honored by your file systems.
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:
[email protected]:~/Documents> touch file1
[email protected]:~/Documents> echo "Some awesome file content" >> file1
[email protected]:~/Documents> cat file1
Some awesome file content
[email protected]eweed01:~/Documents>
What attributes does this file have upon creation?
[email protected]:~/Documents> lsattr file1
------------------- file1
[email protected]:~/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 using the chattr
command with +/-
and the attribute.
sudo chattr +i file1
Now try to add another line to this file.
[email protected]:~/Documents> echo "Even more awesome content" >> file1
bash: file1: Operation not permitted
[email protected]:~/Documents>
What about as root? Still not permitted right?
Can you delete it?
[email protected]:~/Documents> rm file1
rm: cannot remove 'file1': Operation not permitted
[email protected]:~/Documents> sudo rm file1
rm: cannot remove 'file1': Operation not permitted
[email protected]:~/Documents>
Notice the message output Operation not permitted
even when using sudo
.
Our POSIX
permissions have not changed if you check:
[email protected]:~/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
:
[email protected]:~/Documents> sudo chattr -i file1e
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.