[clug] Process sandboxing

jm jeffm at ghostgun.com
Sun Jul 17 22:33:24 MDT 2011

On 18/07/11 1:42 PM, Robert Brockway wrote:
> Remember that X-window is network transparent.  You can run a GUI app 
> and remote display it - no need to have an X server running on the 
> server running the app.
The idea I'm thinking of playing with is fully automated, so a gui would 
be a really bad idea.

>> In that case, you might be able to use lxc containers directly; arkose
>> is basically a GUI frontend for LXC.
> I'd recommend OpenVZ over LXC.  It is true that OpenVZ will eventually 
> go away in favour of LXC but in the mean time OpenVZ has greater 
> stability and features.  I expect I'll continue to use OpenVZ for the 
> next 2-3 years and then switch to LXC once it has matured.  I don't 
> expect the switch to be painful at all.
> This is aside from whether containerisation is the right solution for 
> the problem at hand.

I may have mis-spoke about OpenVZ before. I've got to do some more 
digging first. I read a little about LXC on Saturday, but most of the 
stuff I could find was about using it in a manner similar to how you use 
a VM. Tthe material I found on OpenVZ was similar which is why I 
initially concluded it was a poor fit.

The idea I'm thinking of has an architecture where a main program kicks 
off a semi-trusted script supplied by another party. The script then 
uses the main program to provide services. It has no need for anything 
other than: disk to load other modules and store data, a socket to 
communicate with the main program, and, of course,  CPU and RAM.

If you have any good refs that talk about using containers for this sort 
of thing please fire away.


More information about the linux mailing list