Writing Stackable Filesystems
In the wrapfs_unlink example, we suggested that instead of deleting a file, you could rename it, thus saving a single backup of deleted files. Suppose we call this filesystem unrmfs, in which deleted files are instead renamed from their original name F to F.unrm. It might be annoying if all of these .unrm files started appearing in your directory, especially if you're expecting nothing there. Moreover, this kind of functionality also could be used to fool attackers who try to delete log files that may be used to track their actions. To achieve this, however, the .unrm files must not be visible or accessible to users by default.
To hide certain files in a filesystem, you have to do two things. First, prevent the file from showing up in ->readdir(). This is done by writing code in wrapfs_filldir that checks each filename passed to ->filldir() and returning NULL for those files you do not want listed. Second, prevent users from directly looking up the file by its name; this is done by checking for .unrm files in the beginning of wrapfs_lookup.
Of course, hiding those files from all users isn't very useful. Legitimate users must be able to access those files under certain conditions. A simple approach might be to check the UID of the calling process and to hide the .unrm files only from certain users. A better approach would be to use the mother of all system calls, ioctl. In Wrapfs, you can define as many new ioctls as you like, and then write small user-level programs to use those ioctls. This is, for example, the mechanism we use in encryption filesystems for a user-level tool to pass a user's cipher key to the kernel.
For our unrmfs, you could write a restore ioctl that takes a file's name, F, checks whether the file F.unrm exists and then renames F.unrm back to F, effectively unhiding it from unrmfs. The following example shows a sketch of this code:
/* len: length of source file */ newname = kmalloc(len+6, GFP_KERNEL); strncpy_from_user(newname, ioctl_arg, len); strcat(newname, ".unrm"); lower_dir = get_lower_inode(dir); src = lookup_one_len(lower_dir, newname); if (IS_ERR(src)) return PTR_ERR(src); dst = lookup_one_len(lower_dir, name); vfs_rename(lower_dir, src, lower_dir, dst);
Filesystem development need not be difficult. Using stackable filesystems, you can create new, useful and efficient filesystems quickly—all without changing kernels or existing filesystems. The examples in this article hopefully demonstrate the power of stacking, from which you gradually can build more complex filesystems. You can get the FiST software, documentation and many more examples from www.cs.sunysb.edu/~ezk/research/fist. Happy stacking.
Erez Zadok (email@example.com) is on the Computer Science faculty at Stony Brook University, the author of Linux NFS and Automounter Administration (Sybex, 2001), the creator and maintainer of the FiST stackable templates system and the primary maintainer of the Am-utils (aka, Amd) automounter. Erez conducts operating systems research with a focus on filesystems, security and networking.
- Readers' Choice Awards--Nominate Your Apps & Gadgets Now!
- Security Hardening with Ansible
- diff -u: What's New in Kernel Development
- Memory Ordering in Modern Microprocessors, Part I
- Source Code Scanners for Better Code
- Readers' Choice Awards 2013
- Non-Linux FOSS: AutoHotkey
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
- Linux Systems Administrator