NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD Jails

At Tue, 19 May 2020 10:21:52 +0200, Niels Dettenbach <> 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

> 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.


					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgp31NtFP8T45.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index