Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

51–60 of 374 posts

Re: macOS Containers v0.0.1

#52

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

> "Disable System Identity Protection." This is the first thing I do on any Mac OS system before I start using it.

Then you don't know how to use it.

Re: macOS Containers v0.0.1

#53
post #4

Why should anyone trust this website and download the software? There's no indication who made it. Could be malware for all I know.

> There's no indication who made it.

It clearly links to the GitHub where you can click to see all contributors

I suppose the answer to your question is “people who want macOS containers”, whoever they are. As far as malware, I’d employ whatever your standard practices are for installing GitHub projects

Re: macOS Containers v0.0.1

#54
post #45

Earlier quoted context omitted.

>Wouldn't a Linux device, or Linux running on a Mac suit you better? Maybe they want a unixy desktop with working sound ? Half joking, but that's my use case - homebrew is pretty great, most developers use a Mac in my domains of interest so it's always supported. Linux is just too much work (and I'm using Fedora on my desktop). SIP is just false positives and annoyance. I'm on the fence about M/ARM switch since I sti…

> Maybe they want a unixy desktop with working sound ? In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers. However, the UX can still improve. Switching audio outputs with multiple outputs like external displays etc is not very smooth or intuitive. Some bluetooth headsets have issues but…

There's only a 1% chance these days on Linux that your sound won't work or your computer won't sleep when you close the lid or your wifi won't work, or your ethernet, or your cooling, or a peripheral, or CPU/memory spikes.

And a 90% chance it'll be at least one such thing.

Re: macOS Containers v0.0.1

#56

Earlier quoted context omitted.

>Wouldn't a Linux device, or Linux running on a Mac suit you better? Maybe they want a unixy desktop with working sound ? Half joking, but that's my use case - homebrew is pretty great, most developers use a Mac in my domains of interest so it's always supported. Linux is just too much work (and I'm using Fedora on my desktop). SIP is just false positives and annoyance. I'm on the fence about M/ARM switch since I sti…

> homebrew is pretty great I hear this said a lot in passing, and I'm really curious what people mean when they say this.

Perhaps they are talking about Homebrew the package manager [1].

[1] https://brew.sh

Re: macOS Containers v0.0.1

#57

Earlier quoted context omitted.

I imagine because if an adversary can a chroot environment, then they can trick anything using that chroot to use different binaries.

I have these thoughts about Homebrew also. macOS apps have to be signed and notarised to run without a warning, which is a pretty big part of the defence picture for this software - the certificates can be revoked at any time to block the software if malicious behaviour is identified. However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/check…

> However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all.

There is: you are running that pip package in a chain of processes: Terminal (or iTerm, or whatever) - your shell - python - pip package. In this chain, Terminal has "Developer Tools" privilege, which allows you to run software, that does not meet the system's security policy.

You can disable this privilege in System settings, Privacy and Security panel.

Re: macOS Containers v0.0.1

#58

How 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…

The transitively linked docs have some answers: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: - Filesystem isolation via chroot(2) - Cleanup of container processes using process group - OCI Runtime Specification compatibility (to the extent it…

> bind mounts via MacFuse

Re: macOS Containers v0.0.1

#60
post #43

Earlier quoted context omitted.

The transitively linked docs have some answers: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: - Filesystem isolation via chroot(2) - Cleanup of container processes using process group - OCI Runtime Specification compatibility (to the extent it…

So essentially a chroot with a bit of make-up and a lot of marketing? Except for bind mounts (not even overlayfs...) there isn't much interesting. > - Host-network mode only Yeah expect a lot of things to break in subtle ways... most containers are developed kinda expecting you have your own network namespace (and that no one else is using ports)

overlayfs and bind mounts are orthogonal:

- bind mounting solves the exposition of filesystem within the root pivot.

- overlayfs solves the persistence efficiency issue using a layered union fs.

> most containers are developed

Most Linux (and Windows) containers. Since these are macOS containers there are no containers developed yet so by definition there is nothing to break.

Post reply on HN