[marcodiego]

*BSD have been quite innovative recently. The pledge and unveil syscalls, although achievable by other means on linux, are very simple and effective for what they do. I don't know a way on linux to use a system on a directory without being root; even if possible I'd still need root to mount --bind some dirs, but definitely something I'd like to do.

I don't think containers should be needed for that.

[geofft]

On Linux, you can do

    unshare --user --mount --map-root-user chroot /path/to/whatever

and if you need to bind-mount some directories, you can do that before the chroot, e.g.,

    $ unshare --user --mount --map-root-user
    # mount --bind /proc /path/to/whatver/proc
    # mount --bind /proc /path/to/whatver/sys
    # chroot /path/to/whatever

without being root. (This requires a sysctl to be enabled for unprivileged user namespaces, which is on by default in the kernel.org tree and I think all major distro kernels have it on now. The feature has been in the upstream kernel since 2013.)

If you want to do this at scale, a handy tool is bwrap(1) from https://github.com/containers/bubblewrap . (The README talks about how bwrap is a setuid program to prevent the need for that sysctl, but it also works great as a non-setuid program when that sysctl is enabled, and its value is it has a bunch of handy command-line flags for this sort of thing. We use it extensively at my workplace in non-setuid mode for things that don't quite need containers but need to see alternative root directories etc.)

[lima]

"containers" are just a combination of multiple kernel features, one of which does precisely that (user namespaces).

[pjmlp]

And were known as vaults on HP-UX 11, back in 2000.

[jerf]

Arguably, the issue with these features isn't their existence, since it's not even that hard to add them to a kernel, relative to the generalized difficulty of adding things to a kernel in general. The problem has been the need for mass awareness and desire for the feature, and that's what's taken multiple decades to emerge. It does no good for a kernel to have a security feature that only a vanishing fraction of developers care about and use.

(And I say "vanishing fraction" relative to the pool of developers as a whole; even if a particular subcommunity uses it extensively that doesn't make it a pervasive request. I can name subcommunities with all sorts of exotic interests that have not penetrated the mainstream yet, like the capabilities-based security community. Someday, when that emerges, we'll all point back to E as a pioneer, but in the meantime, effectively nobody wants it right now.)

[wil421]

Sounds like Jails in FreeBSD. Wikipedia says they were added in 1999.

[hestefisk]

And Zones on Solaris :) phk was the original author of Jails; he wrote an excellent paper called “Defying the omnipotent root”, which I can highly recommend.

[amarshall]

*Confining the omnipotent root

[hestefisk]

Yes indeed! Brain fart, apologies.

[hestefisk]

And LPARs on System z :)

[tyingq]

Both LPARS and z/VM look more like hypervisors to me. Things like containers and chroot probably don't make much sense in the mainframe world since they already had granular facilities to limit access to networks, data sets, etc.

[queuebert]

And VMs on IBM VM/370.

[indigodaddy]

Aren’t lpars quite a lot different in nature than zones and jails though?