At Tue, 19 May 2020 10:21:52 +0200, Niels Dettenbach <nd%syndicat.com@localhost> wrote: Subject: Re: NetBSD Jails > > Am Dienstag, 19. Mai 2020, 03:15:53 CEST schrieb Greg A. Woods: > > > > I still think the security and complexity issues with containers, are a > > very much bigger concern than the pure efficiency losses of running full > > VMs. > This is - from my view - a bit outdated view, because of the development. Sure, doing things smart/clean/elegant is definitely outdated when compared to the way many choose to work. As I said, most seem to see the apparent surface simplicity of "docker pull nginx" as elegant enough. > I would switch over more setups to NetBSD if jails would be available, > because i still prefer NetBSD over FreeBSD on such servers because it > is more Xen (PV) "friendly" at all. I think FreeBSD-style jails would be nice too, but only in theory. They seem to offer much more uniform APIs than that mess in Linux. However after looking at just how much "interference" jails cause in so many (most?) parts of the FreeBSD kernel, I just can't see it as any kind of good idea. It's like a fungus sending its tendrils everywhere adding complexity everywhere. The problem is that it seems unix-y monolithic kernels just are not architected well enough to make it easy to add such "isolation" features without either impacting whole swaths of subsystems, and/or introducing new APIs for practically everything (beyond POSIX). Maybe there's a better way to integrate jails using something like secmodel_extensions(9) (where we already have "curtain mode" and non-superuser CPU affinity control)? The odd thing is I think the advantage Linux containers (CGroups and namespaces, etc.) have is that their unique APIs allow them to be more cleanly integrated into the Linux kernel (though I can't say for certain, having not really looked at the code). I haven't looked enough at Solaris yet either to see how zones impact its kernel, though given what else I've seen of Solaris in general, I do hold out some hope that it is integrated in a more structured way, and I think they avoid at least some of the necessity of doing container management with unique new APIs the way Linux must. One of the things I've been hoping to learn in this discussion is more concretely what the true low-level requirements are, over and above what can be done with existing chroot and user/login-class rlimits in order to provide useful isolation of applications. If I look at an example list of "features" of various isolation and virtualization technologies, such as the on on Wikipedia[1], most of what I see in the comparison columns are things that OS academics would find cool and interesting, rather than requirements driven features. So what more is needed, beyond chroot and login classes, to make possible the kinds things like allowing a customer to install web-app "plugins" to their instance of a web server? I can't think of _anything_ else that's _actually_ needed, other than management tooling to make it all clickety-web-GUI-ish. You certainly don't need/want to give them root in their chroot. [1] https://en.wikipedia.org/wiki/Operating_system%E2%80%93level_virtualization_implementations#Implementations -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp31NtFP8T45.pgp
Description: OpenPGP Digital Signature