On Sat, Nov 26, 2016 at 3:23 PM, Maarten de Vries <maarten@de-vri.es> wrote:
On 26 November 2016 at 15:08, Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
Another very useful case would be using containers as a chroot replacement for having clean (only what's in the recipe), reproducable build environments for building arch packages. It would also allow installing makedeps only in the container/chroot or make cross-compilation easier to manage.
Are there plans to support this in makepkg? I believe xbps has this.
To my knowledge, makechrootpkg uses systemd-nspawn, which means it is already using a container. Reproducible builds will need quite a bit more work than simply using containers though.
And since this whole thread is widely off topic already, there is a totally different approach to isolating untrusted apps: cloudabi [1]. Instead of making isolated traditional posix environments to run untrusted applications, cloudabi makes it impossible to access global resources such as the filesystem and network by providing only a subset of system calls. For example, there is no `open()` syscall, but there is `open_at()`. Resources can be given to the process by leaving open file descriptors when it is exec'd, or by sending file descriptors to it over a unix socket.
The biggest drawback is of course that existing software can't simply run under cloudabi because there are syscalls and libc functions missing. Also, controlling access to network resources is troublesome, but I like the general idea: instead of adding complexity of multiple isolated environments, cloudabi removes complexity by stripping system calls that can access global resources. There is a working patchset for the Linux kernel already, though not upstreamed yet. See [1] if you're interested.
[1] https://nuxi.nl/
I know CloudABI from FreeBSD, where it's integrated like Capsicum and netmap have been for a long time. It's unfortunate Linux suffers from NIH in this context.