Is there a way to protect a file in such a way that even root cannot delete it or rewrite it after creating it? I have a file which is created by root under /var/log/ and I want to restrict all users (including root) so that they can just read this particular file after it has been created.

  • If you want a way to stop even root, completely, then you need mandatory access control. see en.wikipedia.org/wiki/Mandatory_access_control It may however be more complex than you need. Protecting the one file is not enough, as a change to any significant system file could be used to circumvent it. Dec 16, 2013 at 22:30
  • 2
    This is not a duplicate of How do I make a file NOT modifiable?! This question asks for something that root cannot undo. The other question only addresses the cooperative case. Dec 17, 2013 at 13:40

7 Answers 7


No there is no way to do this, to my knowledge. The answer about chflags pertains to BSD variants. A similar command for Linux is chattr.

The concept of the root user is that they can do anything on the system.


You may be looking for the "system immutable" flag. The details may depend on precisely which operating system you're running, but the basic idea will be the same. You'll want something like this in BSD (or OSX):

# chflags schg /path/to/file

or the equivalent in Linux:

# chattr +i /path/to/file

Note that root can always remove the system immutable flag in order to change the file, so your next option is to place the file on a read-only filesystem. Even so, with root access one might still be able to unmount a read-only filesystem and mount it read-write.

The next step would be to put it on a physical disk that has a write protect switch. Check with your vendor to see if this is available with your hardware. If it is not, you could consider putting the files on a WORM drive of some sort. A CD-R is an option.

What about putting the file on a read-only NFS filesystem stored on another server?

Probably easier to figure out a better solution to this XY problem.

  • It is a modified version of SUSE Linux. Not sure if this command is available in it. I will check it later.
    – coffeMug
    Dec 16, 2013 at 20:06
  • 1
    chflags is for BSD variants, chattr might do what you want. en.wikipedia.org/wiki/Chattr
    – slm
    Dec 16, 2013 at 20:11
  • @slm, good catch, I guess I'm showing my colours. :-) I've updated my answer.
    – ghoti
    Dec 16, 2013 at 20:30
  • or write to /dev/printer Dec 16, 2013 at 22:35

Generally speaking, root can do everything. Whatever steps you take to prevent root from doing something (such as setting file attributes), root can undo.

OpenBSD and FreeBSD have a notion of security level, also known as securelevel. The securelevel is an integer value. If the value is negative or 0, only the usual unix security rules apply. At securelevel 1 and above, a number of restrictions come into place, in particular:

  • It is impossible to reduce the value of the securelevel.
  • It is impossible to load or unload any kernel module. Thus the code running in kernel mode cannot change anymore.
  • Raw access to the memory or block devices is disabled.
  • The chflags system call denies attempts to remove the immutable or append-only flags from any file.

Securelevels 2 and 3 add additional restrictions. The important thing is that it is impossible to reduce the security level without rebooting, even with root access. Thus securelevels bring in restrictions to what root can do, at the expense of making certain maintenance tasks impossible (such as repairing or reconfiguring a RAID array).

Of course these restrictions are only effective against users who do not have access to the physical machine or to a console during boot. The bootloader data (including the kernel file) must be immutable, otherwise a root user could introduce a backdoor and trigger or wait for a reboot.

It may be possible to configure something like this with Linux's security frameworks (AppArmor, SELinux, …), but these are primarily tools to set restrictive policies for processes that are not running as root. If it is at all possible, it would require a lot of care in defining the policy (even in the ordinary case, designing useful policies is hard).

If you don't have the option to restrict root's power in this way, the way to make a file read-only for root is to store it on a different system. Options include:

  • Run the system in a virtual machine and store the file on the host.
  • Store the file on another system accessible via the network.
  • Store the file on a physically read-only media.

Seems like the only valid way is to use chattr command as follows:

chattr +i /var/log/file

This way even root cannot modify the file unless it removes the i attribute from the file.

So it is just one step toward a better protection I think.

  • 2
    I would consider it useless protection, but if you must 8-)
    – slm
    Dec 16, 2013 at 20:15
  • I agree...! ;-)
    – coffeMug
    Dec 16, 2013 at 20:16
  • “root cannot modify the file unless it removes the i attribute from the file”. Or in other words this doesn't actually solve the problem. Dec 16, 2013 at 23:12
  • @Gilles OK true; is there a solution though?
    – coffeMug
    Dec 16, 2013 at 23:19
  • @coffeMug Not on Linux, as far as I know. See my answer for an answer on FreeBSD and OpenBSD. Dec 17, 2013 at 13:45

Will the file be frozen, or do you need to keep writing to it? In the first case, you could put the file on a read-only medium: CD-ROM, flash drive with a physical write-protect switch, etc. (That protects the integrity of the file, but wouldn't prevent root from unmounting it and/or masking it with a fake).

If you want to continue writing to the log file, there's no solution unless you can find a write-once-read-many physical medium: If a file can be written to, it can be overwritten. (For completeness: It is possible to set a file's "append-only" attribute with chattr or chflags, which will protect the file contents from being overwritten. But it is not possible to block root from unsetting this attribute.)


chattr can do this, or at least something pretty close to it. There are two attributes that may be relevant, depending on what exact behavior you want.

For example, you may want to set the a attribute, using chattr +a filename:

A file with the `a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Since this would seem to be a log file, that may be the more appropriate option. Or you can use the i attribute:

A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Note that the superuser can clear these attributes with the corresponding chattr -X command.

  • chattr can do this” — where you mean “chattr cannot do this”, since root can do chattr +i. Dec 16, 2013 at 23:12
  • @Gilles I'm not sure what you're getting at; even the OP's self-answer specifically mentions chattr +i. Even root cannot modify immutable files as long as the immutable attribute is set. I don't think there's anything that root can do that root cannot undo. (Well, maybe encrypting the file and throwing away the decryption key could work, but I don't think that's very useful...)
    – user
    Dec 17, 2013 at 8:01
  • Just because it's a self-answer doesn't mean it's correct. On OpenBSD and FreeBSD, there is an immutable flag that root cannot unset, if the OS is configured for it (which implies a trade-off between security and ease of maintenance). See my answer for details. Dec 17, 2013 at 13:46
  • @Gilles Of course a self-answer is not necessarily correct, but in this case it does state that chattr is a "valid way" to do what the OP is trying to do. (It was also posted about ten seconds before my answer, which is a big reason why I'm leaving my longer answer around.)
    – user
    Dec 17, 2013 at 13:48
  • And in the comment exchange: “this doesn't actually solve the problem.” — “OK true”. Your answer, like coffeeMug's, would be ok for the duplicate question, where a cooperative solution is good enough. But this question requests security from root. Dec 17, 2013 at 13:58

This doesn't answer the exact question asked, but an alternate solution is to have the log live on a different server / VM, make it append-only using chattr +a and then mount it over the network. This is not without drawbacks, but in my opinion is one of the best approaches to solving this problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.