Inode flags, a hidden Linux gem

In this blog post, I’m gonna talk about a cool Linux feature called inode flags (Originally published on Medium.com, 16-Jul-2020)

One of the best aspects of my day to day work is that I get to discover many hidden Linux gems, and this case was no different.

I was toying around with some ideas when I stumbled upon what seemed to be a relatively insignificant feature. At first it seemed like yet another esoteric method some hardcore file-systems developer added when he needed an extra flag to tweak and squeeze some extra mips. I would’ve probably skipped it without looking back and overthinking it, but by now I’ve learned that this is the best way to explore the mysteries of my beloved OS.

The name inode flags is rather inconspicuous, as most system programmers can think of at least a dozen possible flags related to inodes. These creatures are the backbone for so many standard mechanisms that this name is indistinctive enough to not stand out.

But, once you start reading the man page about ioctl_iflags , the syscall that allows us to manipulate these flags, you discover a heavenly world of opportunities.

System API

Code-wise, it is quite simple, you need a single call to get the fd of the file that you can then use to manipulate the underlying inode flags:

int attr;
fd = open("pathname", ...);

ioctl(fd, FS_IOC_GETFLAGS, &attr);  /* Read current flags */
attr |= FS_NOATIME_FL;              /* Add desired flag */
ioctl(fd, FS_IOC_SETFLAGS, &attr);  /* Set updated flags */

Useful flags

The interesting part here are the inode flags themselves. There are some that help optimize file-operations, others that manipulate the file operational mode and yes, there are always some exotic flags that even after reading their description twice I still don’t know how it would actually affect the system.

But, inside this haystack I found two shiny needles that really caught my eye and got my heart rate up, and yeah, I know this sounds super nerdy 🙂

• FS_APPEND_FL: Mark a file, so that it can be opened only with the O_APPEND flag.
• FS_IMMUTABLE_FL: The file is immutable: no changes are permitted to the file contents or metadata (permissions, timestamps, ownership, link count and so on).

Not even the superuser

These features could’ve been rendered completely if not for the next cool fact: Even if you are the superuser, you CANNOT work around this protection. Yep, even if you sudo the hell out of a file protected using FL_IMMUTABLE_FL , you will fail miserably:

$ echo "test" > test.txt
$ sudo lsattr test.txt
--------------e--- test.txt
$ sudo chattr +i test.txt # Set FS_IMMUTABLE_FL
$ sudo lsattr test.txt
----i---------e--- test.txt
$ sudo rm test.txt
rm: cannot remove 'test.txt': Operation not permitted
$ sudo chattr -i test.txt # Unset FS_IMMUTABLE_FL
$ rm test.txt
$ cat test.txt
cat: test.txt: No such file or directory

Note: As you can see, we’re using two standard shell applications, lsattr and chattr, to list and change the file attributes respectively.

I don’t know what ideas are crossing your mind while reading this, but I definitely had at least two or three use-cases that could highly benefit from this:

• Using FS_IMMUTABLE_FL to protect configuration files on your system, sort of anti-tampering mechanism
• Using FS_APPEND_FL to make sure no one ever removes your log files, but only appends to them

These are also implementation that have certain repercussions and should be used scarcely, but they are useful nonetheless.

If you have any ideas yourself, or found some more interesting stuff of the sorts, please reach out and let’s talk about them.

Hope you’ve enjoyed and that you can find good use for this information. If you do, feel free to check out other stuff I wrote or subscribe to the newsletter and be the first to enjoy newly released quality content in the future.