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…

If you guessed that it’s now 100% open-source compatible, you are correct!

Even though I ordered the Linux package, Dell cheaped out with a Broadcom wireless card that doesn’t have very good Linux support.  Broadcom does have drivers available, but you have to download and compile the wrapper yourself.  Downloading a new driver and all of the kernel-devel packages is a little harder when your network is not connected…

So to replace the Broadcom, I ordered an Intel 3945ABG card, because it is well supported in Linux.  The kernel has the right drivers already included, so Fedora works right out of the box, even booting off of a live cd.  And not only are the drivers open-source, but they even work better.  My connection time shrunk from 20-30 seconds down to about 5 seconds.  I can live with that!