Inode flags, a hidden Linux gem

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, 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.

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

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 */

The interesting part is the 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 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).

These features could’ve been rendered completely if not for the next cool fact: Even if you are a privileged user, 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 ./ioctl_iflags.out test.txt 16 1 # Set FS_IMMUTABLE_FL
Set flag 16 for test.txt
$ sudo rm test.txt
rm: cannot remove 'test.txt': Operation not permitted
$ sudo ./ioctl_iflags.out test.txt 16 0 # Clear FS_IMMUTABLE_FL
Cleared flag 16 for test.txt
$ rm test.txt
$ cat test.txt
cat: test.txt: No such file or directory

The ioctl_iflags.out application is available to you through my GitHub account, find the link at the next paragraph

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. I decided to fiddle with it some more and wrote a small and simple test application I’ve then uploaded to GitHub for everyone to enjoy. Feel free to check it out and let me know if you’ve discovered some more juicy stuff.

Hope you’ve enjoyed and that you can find good use for this information.