https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
Wouldn't recommend this to people prone to identity crises
[deleted]
macOS Containers v0.0.1
121–130 of 374 posts
Re: macOS Containers v0.0.1
#122Sorry, not disabling SIP for something that I can already do without needing to nobble security policies (and have them reset/impossible due to MDM). If there was user/networking space in Darwin then maybe I'd be interested but...
[deleted]
Re: macOS Containers v0.0.1
#123Can anybody explain, what's the point of Mac containers? Almost nobody uses Mac for container based deployments.
CI/CD workflows most likely. And devshops that have standadised on docker containers for their stacks (mac-based devs in such places suffer a fair amount of papercuts today). Then I guess there are people that are very security minded that might want to run all userland executables in containers (although this project here is not for them I'd say).
Re: macOS Containers v0.0.1
#124How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosyste…
> Does XNU have such namespacing functionality across all its interfaces? I don't think so, but some Docker features could be implemented using XNU sandboxing AFAIK > Furthermore, the existing container ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not. This project is about running macOS containers on macOS. It's not about running Linux containers.
> > Does XNU have such namespacing functionality across all its interfaces?
> I don't think so, but some Docker features could be implemented using XNU sandboxing AFAIK
Theoretically, probably, for coarse-grained yes/no things? I don't think it's able to go much further than "you can use the local network and/or internet" and "you can read/write to the filesystem location corresponding to you bundle identifier `com.foo.bar`" but not "hey let me present you with a namespaced view of loopback or process list".
Also not sure if it can be dynamically set by a parent process for a child? Seems like it's very bundle oriented (except maybe for Apple processes) so not very practical.
Re: macOS Containers v0.0.1
#125I hope their software quality is better than what the page looks like in a small form factor.
Re: macOS Containers v0.0.1
#126Earlier quoted context omitted.
Original author here. Thanks for spotting the typo, fixed. WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.
Docker Desktop doesn’t require me to disable SIP. Why would I use this if it requires that?
Docker Desktop for macOS does full-blown hardware virtualization, which is just silly.
Re: macOS Containers v0.0.1
#127What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that.
Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.
Re: macOS Containers v0.0.1
#128Earlier quoted context omitted.
Yes, they are VMs
I'm probably getting confused between containers and VMs but, sorry, I don't understand what the difference is in the case of MacOS?
It is the same for any OS. Virtual machine boots a separate instance of the whole OS. This is slow, this is often too much isolated (you can't easily/effectively share files between host and guest), you need to set artificial limits on VM disk/memory/cpu. On the other side, containers work in the context of host OS, what means less overhead and easier interaction with host.
Re: macOS Containers v0.0.1
#129https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
Oh wow… please do not do that folks!
I disable SIP because I don't want to use an OS where I cannot debug programs which did not consent to be debugged. macOS makes it impossible to inspect failure states I encounter in normal usage (like I can on Linux with debuginfod enabled, or Windows with .pdb files) without first rebuilding the program in debug mode.
Re: macOS Containers v0.0.1
#130What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that. Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.
> Would I be distributing parts of macOS in my containers?
Unless you're producing fully static binaries (or static enough that they don't bind to non-redistributable things) it'd be a yes (it would not be much of a container if it needed non-packaged things)
The screenshot points out a ghcr.io URL that lands on these packages: https://github.com/orgs/macOScontainers/packages?repo_name=m...
Edit: There's a note here†, so at least there is some consideration for licensing. No idea if it holds ground.
† https://github.com/macOScontainers/macos-jail/blob/9b1d5b141...