Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

Post reply on HN
Print view View original

271–280 of 374 posts

Re: macOS Containers v0.0.1

#271

Post by insanitybit »

dartos wrote: post #268
insanitybit wrote: post #224

Earlier quoted context omitted.

I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.

How so? I use docker pretty frequently, but I’m sure that my user is part of the docker group before I do, so I don’t sudo anything. Is there anything else I should be doing security wise? I’ve been hearing podman is more secure, but I think it’s still containerd under the hood, so idk how true that is.

In general if you can `docker run` without sudo then that means you have a trivial privesc path since you can do `docker run` with the various flags that run it without any sandboxing, get a shell, and just ask to be let out of the namespace.

The way that podman and newer versions of docker get around this is using unprivileged user namespaces. Unprivileged user namespaces are not a free lunch - in fact, they're a bit of a security disaster in their own right.

Re: macOS Containers v0.0.1

#272

Post by WesolyKubeczek »

duped wrote: post #267
WesolyKubeczek wrote: post #265

Earlier quoted context omitted.

> But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully .

I've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast. I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it? If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app…

> reasonably fast.

But still not "as fast as it gets". And I want it to be as fast as it gets.

Re: macOS Containers v0.0.1

#273

Post by thtmnisamnstr »

therealmarv wrote: post #240

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631

This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud (https://earthly.dev/). Even the free tier includes arm64 remote runners.

Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.

Re: macOS Containers v0.0.1

#274

Post by duped »

WesolyKubeczek wrote: post #272
duped wrote: post #267

Earlier quoted context omitted.

I've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast. I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it? If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app…

> reasonably fast. But still not "as fast as it gets". And I want it to be as fast as it gets.

Neither is using macfuse as a stand in for overlayfs and bind mounts.

My point is "as fast as it gets" is using MacOS how MacOS is designed: ie, through sandboxing and not containerization that pretends the MacOS userspace is Linux. It's not Linux.

There is a fundamental trade off between isolation and performance. You cannot securely share resources without overhead.

Re: macOS Containers v0.0.1

#275

Post by notnmeyer »

donatj wrote: post #134
lloeki wrote: post #130

Earlier quoted context omitted.

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

Counting the hours until this gets DMCA'd out of existence

folks have been building macos vm images, sharing them, and virtualizing macos on macos for a decade or so now.

is this that much different?

Re: macOS Containers v0.0.1

#276

Post by sofixa »

eviks wrote: post #211
sofixa wrote: post #106

Earlier quoted context omitted.

It only upgrades PostgreSQL 3 major versions up alongside without asking.

Think this issue was fixed a few years ago

Not sure I agree, when I use brew it still regularly updates random unconnected crap through multiple major releases. And of course it takes ages doing so

Re: macOS Containers v0.0.1

#277

Post by shepherdjerred »

dingi wrote: post #94

Can anybody explain, what's the point of Mac containers? Almost nobody uses Mac for container based deployments.

At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead.

[0]: https://github.com/shepherdjerred/macos-cross-compiler

Re: macOS Containers v0.0.1

#278

Post by shepherdjerred »

da39a3ee wrote: post #95

I use MacOS and am very positive about it. I have lots of reasons to run Linux containers. What are some reasons I might want to run a MacOS container?

At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead.

[0]: https://github.com/shepherdjerred/macos-cross-compiler

Re: macOS Containers v0.0.1

#279

Post by crabbone »

timcobb wrote: post #204
crabbone wrote: post #203

Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...

Version 0?

I believe at least some semantic version parsers would not accept version zero. I'd need to find the definition though. I could be wrong of course.

Re: macOS Containers v0.0.1

#280

Post by saagarjha »

slonopotamus wrote: post #81
maggit wrote: post #33

Earlier quoted context omitted.

"System Integrity Protection (SIP)" seems to be the correct name here, for anyone as confused as me :) (More details here: https://support.apple.com/en-us/102149 )

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.

No, that's not true. Turning off SIP is usually about equivalent to allowing instant escalation to root privileges; sometimes even worse.
Post reply on HN