Encrypted File Systems, Part 4

When I finished part three of this series, I didn’t think there was much left to describe. The only thing that I was still puzzled about was how to automatically unmount the TrueCrypt drive when I logged off (which I haven’t had a chance to work on yet); once I’d finished that, I would be done with the topic. Or so I thought.

One thing I hadn’t considered: what to do when something goes wrong.

I found a neat little program today, called Thinking Rock. It’s a program for organizing your work in the Getting Things Done (GTD) system. I like this system, and I’ve been using it for a few years, but I’ve never gotten the time to write a program to organize things as I liked. It looked like this one might do what I wanted, and as it’s written in Java it’s extremely cross-platform, so I decided to give it a shot. (If it’s good, I’ll write a separate entry on it later.)

Setting it up on the Linux box took a little work, but I figured it out with minimal effort and a little ‘net research. Running it required starting a terminal, because you had to change to it’s directory before starting it. That was a pain in the tail, because a shortcut couldn’t do it directly, so I wrote a little three-line shell file to do so automatically. And of course, I named it thinking-rock.sh.

Unfortunately, the file that you run to start the program is also named thinking-rock.sh. That wouldn’t be a problem (my file is in a different directory), except that it also slipped my mind that Linux checks the path before the current directory, unlike every other OS I’ve used. Experienced computer people have probably already guessed what happened next: I’d set up my file to call their file by calling thinking-rock.sh, when I should have been calling ./thinking-rock.sh. The result: an endless loop that ate up all of the memory that the Linux machine had available, then started in on the swap space. The system was swapping so much that it was all but locked up, so after wasting nearly half an hour trying various things, I gave up and restarted it. I’ve had to do this before, and I had no major problems… but I didn’t have an encrypted home directory at the time.

When it started back up, I confidently tried to log in… and failed. It said that it didn’t know my username or that I’d entered a bad password. After several tries, and checking that I hadn’t accidentally turned on the caps-lock, I realized that something had gone seriously wrong.

As my friend Don is wont to say, I’ve learned my way around computers by screwing everything up at least once. I knew that the recovery terminal (that I’d used in part three) wasn’t going to do the trick this time, since it wasn’t accepting my username and password. So I tried something else: control-alt-F1, which switched me to a text mode console. When I tried to log in there, the system told me the problem: the encrypted file system couldn’t be mounted.

By this time, I had enough experience with TrueCrypt under Linux, and with Linux itself, to have a good idea what to do. I logged in as root (the only other account on that machine), half-mounted the drive, then ran fsck /dev/mapper/truecrypt0 on it. It flashed something about replaying the journal, and two seconds later it said the file system was clean.

An exit command logged the root account out, and alt-F7 switched back to the GUI, still patiently waiting for a login. This time everything worked, and I was back in business.

Good judgment comes from experience, and a lot of that comes from bad judgment. Derek Sanderson

2 Comments

  1. Very interesting story. By the way, there’s a rational reason for this counter-intuitive behavior. You wouldn’t want to change a to a directory, and run “ls”, for example, (which is not a shell built-in), and it happen to be a program in that directory that’s a trojan. Hence the default behavior.

    You could re-do your path to have the current directory first, but it’s really not a great idea, for the above reason. Instead, have ~/bin as part of your path (checking for its existence with “test” perhaps before setting it), putting your scripts there. (That way you don’t need to change to their directory, or use root or sudo to create them either.)

  2. I hadn’t thought about the reason behind that behavior, but that’s a good point.

    I wasn’t planning to change it, I’m flexible enough to adapt to it. I simply forgot that time… this Linux stuff is still relatively new to me.

Comments are closed.