I have a small, low-power x86 Linux box sitting on the internet. I want to use it to set up an automated build system for FFmpeg. To what end? At the outset, I would like to validate that the entire codebase builds, with all extra modules enabled, under different gcc versions and post results to a webpage.

The process outline is pretty straightforward. At periodic intervals:

• check out a fresh copy of the FFmpeg SVN tree
• ‘configure’ with all relevant options and the desired compiler version
• ‘make’, log the stdout and stderr text in separate text files
• log the status report to a public website

Pretty simple so far. Other ideas include compiling with multiple compiler versions, including cross-compilers for multiple platforms; automated regression testing; aggregated results sent to a new mailing list [insert your brainstorm here]. I’m starting small because this particular machine requires almost a half hour to complete just one FFmpeg build.

Here is the big item I’m concerned about: How to guard against malicious script injections? Not to say that I don’t trust my FFmpeg brethren but… I can’t think of a good way to end that sentence. But think about it: When you run the configuration script and Makefile, you’re executing free-form shell commands. One of the worser-case scenarios:

all:
    find / | xargs rm -rf

“But Mike,” I hear you exclaim, “as long as you run it as your own unprivileged user vs. root, it won’t destroy the entire system.” That’s terrific news; the easily replaced Linux base system would be safe. So what about running the build process as a heretofore non-existent user (something other than ‘nobody’ since a standard Linux box is going to have files owned by him)? Random shell commands could still, for example, read world-readable files and transmit them offsite. What kind of files? I’m not interested in the fine details, it’s still a security hole.

So there is the possibility of switching to the unknown user in its own chroot’d shell. Ideally, this environment would:

• prohibit network access (setup process gets the fresh SVN tree before entering chroot shell)
• have access to various build tools

I guess what I’m wondering is: Have these problems already been solved? Are there open source projects that already provide good solutions to these problems? Otherwise, I already know it’s a lot of work to set up such an chroot environment (and I have no idea how to prohibit network access for a particular user).