Linked by Thom Holwerda on Sat 2nd Feb 2013 01:47 UTC, submitted by rohan_p
Thread beginning with comment 551279
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by Laurence
by Laurence on Sun 3rd Feb 2013 18:33
in reply to "RE[3]: Comment by Laurence"
...but so does OpenVZ (and LXC), even more so than Virtualbox since they are on the OS-level. Wouldn't they be even easier to break out of?
As far as I know, they don't share services in quite the same way. At least what I've read would suggest that. But I may well be wrong there.
Also, OpenVZ is a ginormous 3rd party kernel patch and I'm not sure how great that is for security
That's a fair concern. I guess peer review is will highlight any issues - in time.
RE[5]: Comment by Laurence
by Alfman on Mon 4th Feb 2013 05:55
in reply to "RE[4]: Comment by Laurence"
Laurence,
"As far as I know, they don't share services in quite the same way. At least what I've read would suggest that. But I may well be wrong there."
I've worked a bit with linux containers/namespaces, and they are great, very elegant. I only wished there were better userspace tools to make arbitrary adhoc process containers in much the same way KVM could make adhoc VMs, which is exactly why I wrote my own. Containers are pretty easy to work with in code (though at the time I wanted to punch someone over the linux+distro interface breakages, hopefully that's settled now).




Member since:
2005-08-18
...but so does OpenVZ (and LXC), even more so than Virtualbox since they are on the OS-level. Wouldn't they be even easier to break out of? Also, OpenVZ is a ginormous 3rd party kernel patch and I'm not sure how great that is for security
That said, I do agree that OpenVZ/LXC would probably be a more efficient solution for this use case.