Josh Stone

I recently read an LWN article on David A. Wheeler’s essay, “Fixing Unix/Linux/POSIX Filenames.”  The gist is that he thinks the filename rules are too permissive — we have ‘/’ as the path separator, and a raw 0 terminates the path, but anything else is fair game.  On the surface, this has a certain beautiful simplicity to it.  However, there are characters that have special meaning depending on the context, so almost any code that actually tries to interpret a filename will have to add a lot of complexity to be robust.  The essay delves into many ways that things can go wrong.

Filenames have been this way in for a long time though, and I don’t expect that this will change officially anytime soon.  Still, my day job now is developing SystemTap, and this sort of problem is one of many sorts that SystemTap can address.  Here’s a script to show how a system administrator could patch the kernel with their own addendum to the filename rules:

#!/usr/bin/stap -g
# badname.stp
# Prevent the creation of files with undesirable names.

# return non-zero if the filename should be blocked
function filter:long (name:string)
{
  return euid() && isinstr(name, "XXX")
}

global squash_inode_permission
probe kernel.function("may_create@fs/namei.c")
{
  # screen out the conditions which may_create will fail anyway
  if ($child->d_inode || $dir->i_flags & 16) next

  # check that the new file meets our naming rules
  if (filter(kernel_string($child->d_name->name)))
    squash_inode_permission[tid()] = 1
}
probe kernel.function("inode_permission@fs/namei.c").return !,
      kernel.function("permission@fs/namei.c").return
{
  if (!$return && squash_inode_permission[tid()])
    $return = -13 # -EACCES (Permission denied)
  delete squash_inode_permission[tid()]
}

The script starts by defining a filter function.  It first check whether the effective user ID is non-zero, so the root user can bypass the filter.  Then, for the prude admins out there, I’ve chosen to block filenames that contain the string “XXX”.  I intentionally kept this part small for this example, but you could easily write a function covering all of the new rules that Wheeler suggests.

After that is a probe on the may_create function, which is what the kernel calls to validate permissions for new files.  We can call our filtering function from here to see if the filename is OK, but since may_create is an inline, we don’t have a direct way to influence its result.  The last thing may_create does though is copy the result of inode_permission (or permission in earlier kernels), which we can override.  So, we save the filtering decision in a global, and then in a return probe on inode_permission, we can change the successful $return code to our own error value.  Now, any attempt to create a file that doesn’t pass our rules will get an error of “Permission denied”.

This sort of script is really just a band-aid, and it doesn’t do anything to deal with files that already have “bad” names.  Still, I hope this is an interesting example of how easily one can modify kernel behavior with SystemTap.  This script can be a starting point to define and try out your own filename rules, and changes can be reloaded and tested without ever having to reboot.  Once your policy has been decided, you can configure the script to load as soon as the system boots, so you’re always running with your improved filename rules, even across kernel upgrades.

It’s powerful stuff, but don’t let it get to your head… 🙂