Inode extensions and details
You may have noticed from the script in the previous section that the file mode bitvector in the inode contains more that just the file mode. In addition to the standard mode information which may be changed via the chmod command, the type of file is also stored. The file mode bitvector is sumarized in Table 7.8.
Table 7.8. File mode bitvector from the inode. Bolded items are mutually exclusive.
15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |
---|---|---|---|---|---|---|---|
Regular or Simlink w/ 13 or | Directory or Block Dev w/Bit 13 | Char Device or Block w/ Bit 14 | FIFO | Set UID | Set | Sticky | Owner |
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Owner Write | Owner Execute | Group Read | Group Write | Group Execute | Others Read | Others Write | Others Execute |
Upon examining Table 7.8, the lower twelve bits should look familiar as all of these modes may be changed via the standard Linux chmod (change mode) command. These file modes are not mutually exclusive. The upper four bits are used to specify the file type.
Each file is allowed only one type. The file types are broken out in Table 7.9.
Table 7.9. Decoding the file type from the upper four bits of the inode file mode.
Bit from Inode File Mode | ||||
---|---|---|---|---|
Meaning | 15 | 14 | 13 | 12 |
FIFO (pipe) | 0 | 0 | 0 | 1 |
Character Device | 0 | 0 | 1 | 0 |
Directory | 0 | 1 | 0 | 0 |
Block Device | 0 | 1 | 1 | 0 |
Regular File | 1 | 0 | 0 | 0 |
Symbolic Link | 1 | 0 | 1 | 0 |
Socket | 1 | 1 | 0 | 0 |
The inode contains a 32-bit bitvector of flags. The lower word of flags is summarized in
Table 7.10. Some flags may lack operating system support. Investigators familiar with
Windows may know that there is a registry flag,
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate, which can be used to disable access time updating on NTFS directories. Bit 7, no access time updating, provides a similar function on an extended filesystem, but at the individual file or directory level.
Table 7.10. Lower word of inode flags.
15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |
---|---|---|---|---|---|---|---|
File tail not merged | Data written through journal | AFS | Directory has hash indexes | Encyrpted | Don’t compress file | Compressed clusters | Dirty compressed file |
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
No access time updating | No Dump | Append | File is | Synchronous | File is | Preserve for undelete | Secure Deletion |
The high word of inode flags is summarized in Table 7.11. Most of these flags only make sense in the context of ext4 optional features. Bit 28, inode has inline data, is used to store very small files entirely within the inode. The first 60 bytes are stored in the block array (which is not needed to store blocks). If the file grows beyond 60 bytes up to about 160 bytes, bytes 60 and up are stored in the space between inodes (currently 100 bytes). If the file exceeds 160 bytes, all of the data is moved to a regular block.
Table 7.11. Upper word of inode flags.
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 |
---|---|---|---|---|---|---|---|
Reserved for Ext4 library | Unused | Unused | Inode has inline data | Snapshot shrink completed | Snapshot is being deleted | Unused | Inode is snapshot |
23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |
Unused | Blocks past end of file | Inode stores large extended attribute | Unused | Inode uses extents | Huge | Top of directory | Directory entry sync writes |
Huge files specify their size in clusters, not blocks. The cluster size is stored in the superblock when huge files are present on a filesystem. Huge files require the Extents feature. Extents will be discussed in detail later in this chapter. Like in-line data, extents use the 60 bytes in the block array for a different purpose. We have said that an inode is the keeper of file metadata. In the next section we will discuss how to retrieve a file based on information stored in the inode.