chmod decides who may change a file. chattr decides whether the file may be changed at all — by anyone, root included, until the attribute comes off. It is the "are you sure" lock for files that should not move, and one attribute in particular does all the work.
The immutable attribute #
$ sudo chattr +i /etc/resolv.conf
$ rm /etc/resolv.conf
rm: cannot remove '/etc/resolv.conf': Operation not permitted
$ lsattr /etc/resolv.conf
----i--------- /etc/resolv.confWith +i, the file cannot be modified, renamed, deleted, or linked to — not by its owner, not by root's normal tools. The classic use is exactly the one above: pinning resolv.conf against a DHCP client or installer that keeps rewriting it.
The supporting cast #
$ lsattr notes.txt
$ sudo chattr +a app.log # append-only: logs can grow, never shrink
$ sudo chattr -i file # remove immutable| Attribute | Effect |
|---|---|
i | Immutable: no writes, renames, or deletes |
a | Append-only: additions allowed, nothing else |
s / u | Secure-delete / undelete hints (ext-family, spotty) |
c / D | Compression hint / synchronous directory updates |
+a on a log file means an attacker who gains write access still cannot erase history — modest defence, real defence.
The honest limits #
Attributes live in the filesystem's inode — ext4 supports them fully; btrfs, tmpfs, and network filesystems ignore most of them entirely. And immutability stops operations through the filename; root can still boot a live USB, or simply chattr -i first. It is a lock on the door, not a wall around the house:
$ sudo chattr -i /etc/resolv.confClassic permission work is chmod and umask; for threat models where even this is not enough, encryption is the next stop. More in the terminal notes.