File permissions have a gap in them, and it is a big one. Root ignores them. Set a file to 000, lock it down as hard as chmod allows, and root still deletes it without so much as a warning. Most of the time that is exactly what you want. Occasionally it is the thing that ruins your afternoon.
That is the gap chattr fills. It sets attributes at the filesystem level rather than the permission level, and the immutable attribute in particular puts a file beyond reach of everybody, root included, until somebody deliberately turns it off again. Handy on the files you really cannot afford to lose by accident: /etc/passwd, /etc/shadow, a config that keeps getting clobbered by a script nobody has tracked down yet.
Syntax for linux chattr command is
chattr [operator] [switch] [file name]
The operator is + to add an attribute, – to remove one, and = to set exactly the attributes you list and clear the rest.
attribute -i – file cannot be modified, renamed and deleted.
Implementation
Start as root and make a throwaway file with permissions wide open, so there is no argument later about whether permissions were the thing stopping you.
cat > attributed-file
This is my attributed test file.
chmod 777 attributed-file
ls -l attributed-file
-rwxrwxrwx 1 root root 28 May 17 01:25 attributed-file
Now apply +i option on following file.
chattr +i attributed-file
That is the whole change. From here the file can be read and nothing else. Writing to it fails, deleting it fails, renaming it fails, and all of that holds while the permissions still say rwxrwxrwx and while you are still root. Removing the attribute with -i puts everything back.
ls -l attributed-file
-rwxrwxrwx 1 root root 28 May 17 01:25 attributed-file
chattr +i attributed-file
lsattr attributed-file
----i--------e- attributed-file
cat attributed-file
This is my attributed test file.
cat >> attributed-file
-su: attributed-file: Permission denied
rm attributed-file
rm: cannot remove `attributed-file': Operation not permitted
mv attributed-file /home
mv: cannot move `attributed-file' to `/home/attributed-file': Operation not permitted
chattr -i attributed-file
lsattr attributed-file
-------------e- attributed-file
cat >> attributed-file
permission is removed.
rm attributed-file
Reading the lsattr output
That string of dashes is the point of the whole exercise, so it is worth slowing down on. Each position is a separate attribute, and a dash means it is off. Only two letters show up in the example.
The i is the immutable flag, and it is the one you just set. The e stands for extent format, which is how ext4 tracks the blocks a file occupies. It shows up on basically every file on a modern ext4 filesystem and has nothing to do with anything you did, so do not read anything into it.
After chattr -i runs, the i disappears and the e stays. That is the file back to normal.
Other attributes worth knowing
Immutable gets all the attention but it is not the only one, and the append-only attribute is arguably more useful day to day. A file with +a set can be added to but never truncated or overwritten, which is the exact behaviour you want on a log file. Processes carry on writing to the end of it quite happily, and nothing can go back and quietly edit what is already there.
That distinction matters if you are thinking about tamper resistance. Immutable stops a log being written at all, which usually breaks the service doing the logging. Append-only lets it keep working while still making the history difficult to rewrite.
Worth knowing too that not every filesystem supports every attribute. These behave predictably on ext2, ext3 and ext4, which covers most of what you will meet. Elsewhere the support is patchier, so check before you build a process around it.
Where this catches people out
The failure mode is always the same and it is always confusing the first time. Something breaks, the error says permission denied or operation not permitted, you check the permissions and they look completely fine. You are root. It makes no sense.
Package upgrades are the usual culprit. Set an immutable config file, then run an update that wants to replace it, and the package manager fails on a file it has every right to touch. Backup and restore tools hit the same wall. So does a colleague, six months later, with no idea the attribute exists.
Two habits make it painless. Run lsattr before you start blaming permissions, because it takes a second and it answers the question outright. And write down what you have made immutable somewhere other than your own memory, because chattr leaves no trace in ls output and nobody thinks to look for it.
Immutable attributes are one of two things that make Linux permissions behave in ways ls -l cannot explain. The other is Access Control Lists, which bolt extra per-user permissions onto the standard owner and group model. Both are invisible in a normal directory listing, and both are worth ruling out before you start doubting your own understanding of permissions.
