Re: OS-level virtualization

[Austin Kim <freennix%gmail.com@localhost>]

On Apr 8, 2021, at 12:12 PM, Rhialto <rhialto%falu.nl@localhost> wrote:
> 
> On Tue 06 Apr 2021 at 20:01:15 -0400, Austin Kim wrote:
>> On Apr 6, 2021, at 2:16 PM, Martin Husemann <martin%duskware.de@localhost> wrote:
>>> Yes, but there are various KAUTH_REQ_PROCESS_CANSEE* that solve parts of
>>> that problem. Some more may be missing.
>>> 
>>> Martin
>> 
>> Hmmm? Now I?m starting to wonder how much of the equivalent
>> functionality you could achieve just through judicious use of
>> chroot(2) and kauth(9) alone ?
> 
> I had the same idea in the past, but haven't done anything concrete with
> it.
> 
> For faking separate PID 'namespaces', you could get away with just
> hiding processes that you're now allowed to see. PIDs are random anyway
> so you won't really notice.
> 
> For other things, like UIDs, GIDs, etc it is a bit trickier because you
> could get multiple 'namespaces' using the same value and you can't even
> prevent it without causing weird failures. For those, you'd need some
> mapping layer somewhere to translate between global values and
> inside-the-namespace values. There is something like that for stacked
> file systems (mount_umap)  but that won't be enough.
> 
> Maybe we can invent something cleverer than Linux. Syscall interception
> layers as a file system perhaps?
> 
> -Olaf.
> -- 
> ___ Q: "What's an anagram of Banach-Tarski?"  -- Olaf "Rhialto" Seibert
> \X/ A: "Banach-Tarski Banach-Tarski."         -- rhialto at falu dot nl

Thanks for the insights; another issue might be the need to bind the sandboxed, OS-level-virtualized instances to specific IP addresses while disabling raw IP sockets.  The more I think about it, the more exponentially complex this suddenly seems to become.

I think for my use case (supporting multi-tenancy for unrelated clients who have no mutual trust relationships on physical racks), the combination of using ZFS + chroot(2) + kauth(9) where needed would suffice; but the idea of implementing a more general OS-level virtualization system on NetBSD is hella intriguing.

Zooming out, in the grand scheme of things, as desirable as having a NetBSD counterpart fo Illumos Zones or FreeBSD Jails would be, I realize this is down the list of priorities behind migrating NetBSD’s SCM system from CVS to Git being the first priority followed (IMHO) by getting root on ZFS integrated into _sysinst_.  Both are things I would be interested in contributing to one day (but can never seem to force myself to make free time), though in the case of the former, while I’m ok decent with Git, to be able to contribute anything useful I’d obviously have to get more intimately familiar with CVS (but am really dreading sitting down to read up on CVS; I’d even prefer Subversion or Mercurial over CVS).  I feel like (though I don’t have any evidence to back this up) perennially never attaining critical mass to migrate to Git is potentially turning off potential new users and developers to the project (particularly fresh young CS/CE talent coming out of schools and universities where Git is pretty much the standard SCM system taught today—imagine if you came across a Web site about an OS you weren’t previously familiar with but upon further reading found out it was still using SCCS or RCS as its VCS and how that might affect your perception of the project), but that is the topic of a completely different thread entirely.  (Sorry I got off topic; recently came across some old articles about FreeBSD’s 2012–13 transition from CVS to SVN and more recently from SVN to Git and was just floored thinking about the technical heavy lift and engineering challenge that must have involved on the part of so many people and just awestruck how they in the end managed to pull it off…)

Austin

“We are responsible for actions performed in response to circumstances for which we are not responsible.”  —Allan Massie, _A Question of Loyalties_, 1989