Walton Hoops - aka Whoops!

For those who might not know, Project Euler is a site which provides a large collection of problems designed to be solved with a program. Many of the top problem solvers list pencil and paper as their programming language, however. Euler problems are designed to be solvable in less than a minute. While many can be solved by brute force, most will need a more well-thought out approach to solve them within a reasonable time frame.

Project Euler has been on my radar for awhile now, but I’ve only recently started working on it. It’s proving a great way to practice and learn new languages. I’ve primarily been solving problems with Haskell, but I also have several solutions in Common Lisp and Racket. Haskell seems especially well-suited for many of the puzzles on Euler. Dealing with infinite streams is a common theme and Haskell’s lazy evaluation shines there. It’s not uncommon to set up the problem in the most obvious way, then let laziness ensure that you don’t do any more work than necessary. Though I’d love to give an example of this, Project Euler discourages sharing solutions online so as not to spoil anyone’s “Ah Ha!” moment.

If you’re looking for a way to practice your skills or learn new languages, I highly recommend giving Project Euler a look. Or if you want something a bit less mathy, check out Code Wars. Unlike Project Euler, it’s not language agnostic: they currently support Ruby, JavaScript and CoffeeScript. Support is also on the way for Python, Haskell, C# and Java. Unlike Euler, Code Wars also has a big focus on TDD which might be a plus for some people.

In my efforts to learn Lisp, I started using StumpWM. Using a window manager configurable in Common Lisp seemed like a good way to practice, and as it turns out, I fell in love. It uses keybindings and acts similar to Emacs or Tmux, which for me at least makes it much nicer to work with than xmonad or awesome.

Coming up with a configuration that worked for me took some effort, so I thought I’d share what I came up with. Here it is:

I recently had to build a chroot jail in order to run an executable I didn’t write in a secure enviorment. As this isn’t something there are many tutorials for, I thought it might be benificial to write one. Note that properly securing the jail is beyond the scope of this article and is better covered elsewhere. Instead this will cover how build a chroot environment with the dependencies your program needs to run.

So without further ado, let’s build a chroot environment. For this example we’ll secure /bin/date. So let’s create a chroot directory and copy the executable in.

mkdir ~/chroot
mkdir ~/chroot/bin
cp /bin/date ~/chroot/bin

Step 1: Finding the needed shared libraries.

Well, that was easy enough, let’s go ahead and try to chroot. Note that only root can chroot, so you will need to use sudo or su, whichever is appropriate for your setup.

$ sudo chroot ~/chroot/ /bin/date
chroot: failed to run command ‘/bin/date’: No such file or directory

This error might make you think that /bin/date is missing, but that’s not the case. What is actually happening is the system is unable to locate the shared libraries required. Lets figure out what those are.

Notice linux-vdso.so.1 does not have a file associated with it. That’s because this is a special shared library provided by the kernel.

Now try running inside your chroot jail again:

$ sudo chroot ~/chroot /bin/date
Thu Apr 19 02:51:12 UTC 2012

Ok that looks pretty good, but compare that to running outside the chroot

$ ~/chroot/bin/dateWed Apr 18 22:52:01 EDT 2012

Notice that the timezone is wrong when run inside the chroot. Let’s see if we can figure out why in step 2:

Step 2: Finding needed files

There is no sure way to find all the files that your process is going to need, but most of the time you can take a pretty good guess as to most of them. For example if you’re chrooting Python, you probably need all those files from a standard Python install. For those that aren’t obvious, there is one tool that can help you. strace lets you capture all the system calls that a process is making. The -e option lets you watch for a specific call. So let’s try it on our date program.

Ok, so the first few are attempting to dynamically load some libraries, which may sometimes be important for your process, but in this case we can get away without them. The last one however is important. So let’s add /etc/localtime to our chroot directory.

Bingo! Correct time and timezone. Hopefully this will help anyone having trouble getting programs to run inside a chroot jail. If you have any questions or comments, feel free to reach out to me on Twitter or GitHub.