jkraemer.net

Today I had some fun tracking down a weird problem with safe_erb. While everything worked fine running Mongrel in development mode, safe_erb complained about outputting tainted strings for every link generated by Rails’ link_to and URL helpers running on mod_rails in production mode.

Some digging around led me to the root of the problem - in production my app needs to live inside a subdirectory and so I used Passengers RailsBaseURI directive to tell it so. The value configured this way ends up tainted in AbstractRequest’s relative_url_root for some reason, which in turn makes every URL generated by Rails tainted.

Solution

class ActionController::AbstractRequest
  def relative_url_root_with_untaint
    relroot = relative_url_root_without_untaint
    relroot.untaint if relroot =~ /^\/[a-zA-Z0-9]*$/ or relroot.blank?
    return relroot
  end
  alias_method_chain :relative_url_root, :untaint
end

This untaints the relative_url_root value if it matches the regexp. Place into application.rb or some file that is required during application startup to fix the problem. I’m still not sure whether this is a bug and if so, whose bug it is - should (if possible at all) mod_rails untaint this value in the first place, or is it a bug with Rails not escaping something somewhere?

The fact that URLs used with Rails’ form helpers didn’t yield safe_erb errors, but those supplied to link_to did makes me think that there’s at least some inconsistency in the way URLs are treated by Rails’ helpers…

In order to give my trusted T42 a slight speed up I decided to replace the built-in 5400rpm hdd with something faster. I decided to go with Seagate’s ST910021A which seems to be a great choice from what I can tell so far - it’s noticeably faster and despite it’s 7200 rpm it’s nearly as quiet as the original 80GB disk from Hitachi.

But I digress. Initially I just wanted to copy over all the stuff and be done with it, but then I took the chance to do a fresh install of Ubuntu so I could try out the hard disk encryption setup that has been introduced in the alternate installer of 7.10. Until then I only had an encrypted /home, which was pretty useless since most of the time my notebook isn’t shut down but hibernated, and I never needed to type in my passphrase upon resume…

This turned out to be really easy. By far not the most secure setup, but should stop the average thief from using the logins stored in my firefox ;-)

The following steps assume you have a recent Ubuntu (Debian might work as well) with a recent Kernel - 2.6.12 is known to work. As encryption works partition-wise, your /home needs to be on it’s own partition, /dev/hda6 in my case.

These steps worked for me, but they might as well destroy all your data - but you sure do regular backups, don’t you ?

1. Go into single user mode and backup your home partition to some trusted media (e.g. another hard drive). We’ll need to restore from that backup later, so don’t skip this step ;-)

   cp -a /home/* /some/mount/point

2. Install required tools (you need Universe in your apt sources)

   apt-get install cryptsetup hashalot

3. Unmount the home partition:

   umount /home

4. Initialize the encrypted device. This is the step which wipes out your original home partition, so double check your backup is ok. When asked for the passphrase, be sure to choose something strong. The passphrase will be used to encrypt the key which in turn is used to encrypt the partition. Read the Ubuntu encrypted fs howto for some background on passphrase strength.

   cryptsetup -y -s 256 -c aes-cbc-essiv:sha256 luksFormat /dev/hda6

5. Edit /etc/crypttab and add a line like this:

   /dev/mapper/crypthda6 /dev/hda6 none cipher=aes-cbc-essiv:sha256 luksOpen /dev/ hda6 crypthda6

6. Edit /etc/fstab and change the device in the line which mounts /home from /dev/hda6 to /dev/mapper/crypthda6:

   /dev/mapper/crypthda6 /home ext3 defaults 0 2

7. Try out the cryptsetup initscript:

   /etc/init.d/cryptdisks start

8. Mount your brand new encrypted home dir: mount /home

9. To make sure everything works, create some file in /home, unmount, do /etc/init.d/cryptdisks stop, and start over with /etc/init.d/cryptdisks start, mount /home again and check the file you just created is there.

10. If this worked, it’s time to restore the original contents of /home from your backup:

    cp -a /some/mount/point/* /home/

11. Reboot, type your passphrase if asked, and everything should be fine.

The official cadaver debian package doesn’t support ssl, because of some annoying licensing issues with openSSL. Therefore I recompiled the sarge version of cadaver with ssl enabled. After a bit of reading this turned out to be a quite simple process:

• apt-get source cadaver
• modify debian/rules: make the –without-ssl switch in the call to configure read –with-ssl, and change the package name to cadaver-ssl.
• modify debian/control: change package name again, add the line Conflicts: cadaver to indicate that only the original cadaver _or_ our ssl version can be installed at the same time.
• build the deb using fakeroot dpkg-buildpackage

You can get the result here, or via apt-get install cadaver-ssl by adding the line

deb http://debian.jkraemer.net/apt sarge main contrib non-free

to your /etc/apt/sources.list.

Update (2006/07/12): I fixed the URLs above.