This is a standard (and as safe as the kernel can be, safe) way of sandboxing. We could, for example, run servers in a namespace to test against (even though stubing and the like is better). To break out of a namespace we would have to copy a file or something first, not sure. Need to investigate how docker/lxc handle it. Reproducible: Always
the namespaces that exist in the latest release are not sufficient to fully isolate. they are also not something we'll ever hard require because: - they are frequently disabled by users - many require recent kernel versions that said, i've been toying with using them when they are actually available. the isolation that's available today is nice -- PID & USER & mount.
Ya, I've been meaning to set up a system like rich0 did to test ebuilds.
i've got an implementation now working, but it requires user namespaces when FEATURES=usersandbox is active because portage drops root before executing the sandbox. but maybe we can teach portage to let the sandbox itself do the dropping of accounts ... otherwise, what i've got: - a unique ipc/sysv namespace is created ... i'm not aware of this causing problems for any packages including portage internals - a unique uts namespace is created ... not a big deal, but lets sandbox set a unique/stable hostname, and prevents apps from changing it - a unique net namespace is created ... the only network access apps get are to localhost which prevents rogue network connections and conflicts when running tests. there's overlap here with FEATURES=network-sandbox. - a unique pid namespace is created ... no apps get access to processes outside of the sandbox now, and it's impossible for processes to orphan themselves because when the sandbox exits, the kernel guarantees killing children (whoo) - a unique mount namespace is created ... not that it normally should matter by itself as you don't normally have access to mount/umount - when mount namespaces work, a tiny/reduced /dev/ mount is created. atm only access is granted to: full, null, ptmx, tty, urandom, zero, pts, fd, std{err,in,out}. this will implicitly "fix" many packages that try and poke things like video hardware as the /dev/ nodes won't be visible. also isolates packages that accidentally try to scribble on mem/block nodes. - when mount namespaces work, a unique /tmp/ is created. this guarantees all content is destroyed between phases and ebuilds can't break other packages or system processes (or vice versa). i'm also thinking about white-ing out /run/ and /run/lock/ as i can't think of any state in there that apps inside of the build sandbox should need access to. atm i only have command line flags for controlling things. i want to add support for enabling things via /etc/sandbox.conf before releasing.
initial support released here: http://gitweb.gentoo.org/proj/sandbox.git/commit/?id=d96587d02f203e2c40790ac1c0e5778c6299d1a2 features are defaulted to off but can be turned on by editing /etc/sandbox.conf. once this stabilizes a bit and i can update portage, i'll see about flipping at least some of the options to on.
