I’ve recently solved my 25th Project Euler problem, progressing to level 1!
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.
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.
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.
Ok that looks pretty good, but compare that to running outside the chroot
Wed 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.