How To Set File Attributes In Linux Using Chattr Command

November 13, 2005
Chattr is a command used to set / unset file attributes in Linux. Using chattr it is possible to make a file immutable. That is, even a root user will be prohibited from deleting the file.

The trick lies in setting the appropriate attribute for the file.

chattr command is similar to the attrib command in DOS but much more powerful and flexible.

To prevent anyone - even a root user - from deleting a file, you set the immutable bit of the file using the chattr command as follows -

# chattr +i filename

The immutable bit option +i can only be set by the root user. So either you should have root priviledges or you need to use sudo to execute the command.

Once the +i bit is set, even root user won't be able to delete or tamper with the file.

To unset the immutable flag -

# chattr -i filename

Every file in Linux have a number of attributes associated with it. The immutable bit attribute being just one of them. To see what all attributes are set for a particular file, you run the lsattr command as follows.

# lsattr filename
----i--------  filename

If the immutable flag is set, there will be an i in the listing.

The chattr command is used by system administrators to restrict the users from changing a file in a particular way or even the administrator can by mistake delete a critical file because of a mis-typed command. But if the immutable flag is set, these mistakes can be avoided.

chattr can be used to set/unset many more file attributes.

For example, if you want to allow everybody to just append data to a file and not change already entered data, you can set the append bit as follows:

# chattr +a filename

Now the filename can only be opened in append mode for writing data. You can unset the append attribute as follows:

# chattr -a filename

To know more about chattr command, check its man page.


  • of course remember this only works with ext2/3

  • Can't root just change the sysimmu flag?

  • Yep, but most scriptkiddies won't even know about chattr/lsattr :)

  • Which is exactly why so many root-kits include tools that set the immutable bit.

    Idea is to make it so the system owner, root, can't un-kit his box.

    Seems to me the kiddies are more aware of this than most operators are.

  • Under FreeBSD you use the following to make a file immutable:

    chflags schg

    And to make things normal (make the file mutable again):

    chflags noschg

    Of course if you're running your system multi-user at a secure level where root can change flags at will, it really doesn't buy you anything more than accidental deletion prevention.

    To be secure with FreeBSD, once you've set all the flags how you want 'em, you'll want your system to run at securelevel 1 or higher, which prevents the flags from being changed.

  • you can still bypass the restriction by mounting another filesystem over the top

  • Apreche

    Wow, I'm surprised there is something about *nix I didn't know. You learn something every day. But I probably only didn't know about it because I use reiserfs and xfs. Oh well. I guess I'm save from the kiddies then.

  • correct me if i am wrong, but wouldn't something like just blow this into nowhere?

    for file in *
    chattr -i $file

  • w7: ooooh you're smart.

  • ...or perhaps just chattr -R -i *

  • trungson

    As this command become widely known, it's less of an immutable solution.

  • miscblogger

    this is so cool! does anyone know if there is there a way to do that for windows?

  • miscblogger: lol
    I think all you've got on MSFSs is the Read-Only attrib.

  • Perhaps someone very smart could write something similar to chattr which demands a password before the change could be made. I'm sure it would involve just a few changes to the kernel file system code and modifying the chattr and lsattr commands ;o)

    Perhaps a module for Reiser4 could do it nicely? Something at the file system level which would password protect any files system objects and their attributes.

  • Of course if /bin /boot and /etc are on an el torito bootable CD created on the bench system for the server...

  • immutable isn't the only flag you can use, you can set append only, for instance on a log file so that if the service doing the logging gets compromised it can't erase log entries.

    the whole thing is much more useful in freebsd and such things as it has security levels, in which nobody, even root, can change these flags. additional steps can be taken to ensure that an administrator must have physical access or authenticate in some other way to change security levels.

    on top of that, not all filesystems support these flags, most notably, no version of reiserfs supports them.
    these attributes also have many more uses, but they don't really make sense most of the time. the things just aren't very useful on linux. other unix based operating systems found better uses for such things, but on linux you'll mostly have to use other means to secure your system.

  • You wanna make the immutable bit un-changeable? Look up a little tool called 'lcap'. You may wall have to install it, my FC4 boxen don't seem to include it.

    Here's a script I used back when to 'lock down' my boxen. It was more of a pain in the ass in the long run and there are other, more manageable methods to achieve similar goals:

    # Files with i bit set can't be altered - even by root.
    chattr -R +i /bin /boot /etc /lib /sbin /usr/bin /usr/include /usr/lib /usr/sbin /root/fw
    # chattr +a /var/log/mysqld.*.* /var/log/boot*.* /var/log/cron*.* /var/log/messages*.* /var/log/secure*.*
    # This following will make it so not even root can change the i bits.
    # Once set - this can not be undone without re-booting!!
    # You *must* reboot the system from the console to restore
    # the capability to use chattr to place and remove a or i bits.
    # The following will prevent raw I/O access to change a or i bits, but
    # will break a few things - not suggested.
    # lcap CAP_SYS_RAWIO
    echo "Done - system lock down complete"

    Some background:

    If you use that 2nd lcap line - it will prevent raw I/O operations from changing the a or i bits. But, it'll also make such things - like X - inoperable.

  • Mysidia

    What do you mean make your files immutable, even to root?

    You do realize, root can about blow away the whole filesystem with a simple dd if=/dev/zero of=/de.../hda1, for instance, or by mucking with the partition tables.

    Sure, chattr can save an important file from a typo and has marginal uses for restricting non-roots from erasing certain things, even if they own them, but if you know about chattr, there are much simpler methods of avoiding the accidental deletion, and chattr is generally more annoying than useful.

    As a security measure, I call it, a false sense of security.

    At least until you set securelevel to 2, disable all changing of the flags, mounting/unmounting filesystems, or opening system devices for write access, while in multiuser mode

  • Good information, I have a few more useful commands on my blog. You can few them at Atlas-Tuesday - Log File Unix Commands

    Linux is a fantastic OS for managing files.

  • Immutable files work on XFS. I am using Ubuntu Breezy.
    touch test
    sudo chattr +i test
    sudo rm test
    rm: remove write-protected regular empty file `test'? y
    rm: cannot remove `test': Operation not permitted

  • If you want to stop someone from shutting the immutable flag off after being set you can download the LCAP package. LCAP lets you change kernel options and makes it very easy for you to shut off immutable. This will stop anyone from being able to set the immutable flag at all. However, anything set will remain set. Once you turn off immutable it can't be turned back on until you reboot. So I suggest creating a script and setting it load on any runlevel with networking support enabled. Now any files tagged immutable can't be deleted by anything anymore! I would also set the immutable tag on the script as well so a user can't modify it unless they're in single user mode. I would also suggest turning the append only flag on for your log files. Then turning off the kernel option for append-only as well. This way your logs can have data added to them but they can't be modified. This makes it impossible for an attacker to remove their tracks. Check out Hardening Linux. This trick and others are available in it. This gives you a system similar to BSD secure levels (just not as good).

  • FYI. The MSWin equivlant is the "attrib" command I believe :)

  • We can do that with "chflags" in FreeBSD..
    But how can we do that in SunOS??

  • People are right here, it only prevents accidental deletion. But it also stops some well-known vpn client used at unis and larger companies to overwrite profiles and thus allows to store passwords in those files. To be safe, just mount an encrypted partition, so you only have to enter the password once