Protect a File with chattr Without Losing the Undo Path

chattr sets filesystem flags such as immutable or append-only, protection that survives even a root user's rm until someone switches it off. You will use it to confirm the change with lsattr, and remove it again when the maintenance task is complete. Allow about ten minutes for a single file. You need the e2fsprogs utilities and a filesystem that supports the attribute you choose.

This guide follows the installed chattr from e2fsprogs 1.47.0-2.4~exp1ubuntu4.1. The command is not a general permissions replacement. Attribute support and privilege requirements vary by filesystem, so test on a disposable file before applying a setting to a live path.

1. Inspect the current attributes

Start with a read-only check. It does not need elevated privileges when you can read the directory and file:

$ command -v chattr
/usr/bin/chattr
$ command -v lsattr
/usr/bin/lsattr
$ lsattr /path/to/important-file

The output is a string of attribute letters followed by the path. A dash means that the corresponding position is not set. On a typical ext4 file, e may already be present: it means the file uses extents and cannot be removed with chattr. Do not treat every displayed letter as a setting you can change.

Checkpoint: save the original lsattr output before changing anything. That gives you a useful comparison if a later command fails.

2. Choose the smallest protection

chattr uses a symbolic mode made from an operator and one or more letters. + adds attributes to the existing set, - removes them, and = replaces the set with exactly the letters supplied. Prefer + and - for routine changes because they leave unrelated attributes alone.

For a file that must not be changed, renamed or deleted, the relevant attribute is i, immutable. For a log or evidence file that may receive new data but must not be truncated or rewritten, a, append-only, is usually the narrower choice. Both are security-sensitive state changes. They can interrupt an application that expects to rotate, replace or edit the file.

Only the superuser or a process with CAP_LINUX_IMMUTABLE can set or clear a and i. Plan the privileged step, and keep the inspection commands unprivileged where possible.

3. Apply immutable protection to a disposable test file

Use a test path first. The commands below create a new file in the current directory, so replace chattr-test.txt only with a path you have deliberately chosen:

$ printf '%s\n' 'keep this file' > chattr-test.txt
$ sudo chattr +i chattr-test.txt
$ lsattr chattr-test.txt
----i---------e------- chattr-test.txt

The exact positions and other letters in the output depend on the filesystem. The useful check is that i appears. Once set, the file cannot be written, renamed, unlinked or have most metadata changed. A command can still appear to have access to an already-open file descriptor: the manpage warns that changing a or i does not affect writes through file descriptors that were already open.

Try a harmless write and inspect the status:

$ printf '%s\n' 'this should fail' >> chattr-test.txt
bash: chattr-test.txt: Operation not permitted
$ printf 'write status: %s\n' "$?"
write status: 1

The shell may print a slightly different error. A non-zero status is the important result. An immutable attribute is not encryption, access control for readers or proof that a malicious root user cannot change the file. It is a kernel-enforced filesystem attribute, subject to filesystem support and sufficient privilege.

4. Remove the attribute before maintenance

Do not delete or replace an immutable file as your first attempt to undo the change. Clear the attribute, verify that it has gone, then perform the planned maintenance:

$ sudo chattr -i chattr-test.txt
$ lsattr chattr-test.txt
--------------e------- chattr-test.txt
$ printf '%s\n' 'maintenance can proceed' >> chattr-test.txt

The -i operation is the recovery path for this example. If it fails, stop rather than trying rm, mv or repeated writes. Check the path, filesystem and privilege first:

$ findmnt -T chattr-test.txt -o TARGET,FSTYPE,OPTIONS
$ id
$ sudo lsattr chattr-test.txt

Some filesystems do not support a requested attribute, and a filesystem-specific manual page may impose extra rules. The installed chattr manual specifically points to btrfs(5), ext4(5), mkfs.f2fs(8) and xfs(5) for those details.

5. Use append-only for controlled logs

Append-only is different from immutable. With a, writes must use append mode, while ordinary replacement, truncation, deletion and renaming are blocked. That can suit a log collector, but only if the collector really opens the file for append and its rotation process knows how to clear the attribute during a controlled maintenance window.

$ printf '%s\n' 'first record' > audit-test.log
$ sudo chattr +a audit-test.log
$ lsattr audit-test.log
-----a--------e------- audit-test.log
$ printf '%s\n' 'second record' >> audit-test.log
$ tail -n 2 audit-test.log
first record
second record

Do not use chattr +a as a substitute for log retention, remote collection or tamper detection. It does not stop a privileged operator from clearing the attribute, and it can prevent normal log rotation from doing its job.

To finish the test and restore ordinary behaviour:

$ sudo chattr -a audit-test.log
$ lsattr audit-test.log
--------------e------- audit-test.log

6. Avoid the broad and destructive forms

chattr -R applies a change recursively to a directory and its contents. Treat it as a separate, high-risk operation: one typo can affect configuration files, sockets, caches or filesystems mounted below the directory. Inspect the target with find first, use a narrow file list where possible, and keep a documented reversal such as chattr -R -i DIRECTORY only when you intentionally applied +i recursively.

Be especially cautious with =. A command such as sudo chattr =i file does not merely add immutable; it asks for the supplied attribute set to become the only set, which can conflict with filesystem-managed flags or a previous operational choice. The read-only attributes E, I, N and V may be displayed by lsattr but cannot be set or cleared with chattr.

The c, s and u attributes are not honoured by ext2, ext3 or ext4 in current mainline Linux kernels, according to this manpage. Do not promise compression, secure deletion or undelete behaviour merely because the command accepted a letter. Check the target filesystem's documentation and verify the actual result.

Done means