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

251–260 of 374 posts

Re: macOS Containers v0.0.1

#251

Post by pohl »

xmodem wrote: post #243
pohl wrote: post #228

Earlier quoted context omitted.

The "varsectomy" bug in Chrome isn't the example you think it is, because disabling SIP was not sufficient conditions for it. There were 3 other conditions that had to be met, the most notable of which is that "/" had to be writeable by tho logged-in user, which is not the default. This is an example of defense-in-depth being present, and defense-in-depth still failing for some users who gave escalated permissions to…

The two other conditions listed in the page you link basically amount to "the buggy code has to run". Related, I think SSV [1], introduced last year, would also have blocked this bug even with SIP disabled. But none of that invalidates concern that areas of the OS we don't know about might not have the level of defence in depth that we would like - it's not like Apple has never cut corners or shipped bugs to hit a da…

One can have vague, general concerns about any operating system if one lets their imagination run wild, though, and one doesn't care about the presence or absence of specific examples supporting the suggestion that the "permissions system...makes assumption[s]" about SIP existing.

Re: macOS Containers v0.0.1

#252

Post by jayd16 »

mavili wrote: post #250

When macOS runs on Unix kernel and Linux systems are the best supported for containerisation and I assume are much more lightweight than macOS, I personally don't see any reason to run macOS in a container.

You would do it so you can run mac software in a container.

Re: macOS Containers v0.0.1

#253

Post by fiddlerwoaroof »

jmbwell wrote: post #233
hamandcheese wrote: post #47

Earlier quoted context omitted.

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

They mean they haven’t tried another package manager for Mac, like pkgsrc or macports.

I switched to it after using both Fink and macports and it was the first time I felt like I had a package manager as reliable to apt on Linux. Both Macports and Fink would routinely break my whole system by putting extra versions of system libraries where other applications could find them. Since, I’ve switched to nix.

Re: macOS Containers v0.0.1

#254

Post by pjmlp »

tambourine_man wrote: post #222
pjmlp wrote: post #219

Earlier quoted context omitted.

All of that appeared first in HP-UX, Solaris and Aix. Xenix and Coherent were the first UNIX on consumer hardware.

Which is why I said: “All of that stuff was not a first ever implementation, of course, but it was well executed and led the way.” Apple is rarely the first at doing something but it's often the first that's good and cheap enough that people care about.

Which makes the point that there is hardly any UNIX inovation coming from them.

Please cite a USENIX research paper from Apple.

Re: macOS Containers v0.0.1

#255

Post by slonopotamus »

MuffinFlavored wrote: post #246

https://github.com/macOScontainers/macos-jail - new code https://github.com/macOScontainers/rund - new code https://github.com/macOScontainers/moby - fork, 6 commits https://github.com/macOScontainers/buildkit - fork, 4 commits https://github.com/macOScontainers/containerd - fork, 5 commits Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed

This is a failed attempt to upstream part of containerd changes: https://github.com/containerd/containerd/pull/8789

Other part of containerd changes waits for gods-know-what: https://github.com/containerd/containerd/pull/9054

But I haven't gave up yet.

Re: macOS Containers v0.0.1

#256

Post by duped »

I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function.

I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance.

It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as the Linux userspace, and doesn't have the same kernel features that would let you do so cleanly or performantly.

Orbstack is moving mountains to provide Linux-native perf and support for containers and it still makes me beg the question: why are devs allergic to just using Linux natively? At least I understand why Orbstack is useful, I don't know why containerizing MacOS itself is.

Re: macOS Containers v0.0.1

#257

Post by duped »

nyanpasu64 wrote: post #171
smcleod wrote: post #157

Earlier quoted context omitted.

I’ve never had problems debugging anything with SIP on.

My experience is that I was unable to debug Maestral (a Python program) crashing in native Cocoa bindings in LLDB, because the interpreter did not allow itself to be debugged. Mozilla says Firefox acts the same way at https://firefox-source-docs.mozilla.org/contributing/debuggi... . It's possible there's some workaround I'm not aware of, but I ended up disabling SIP just like every non-macOS computer I own.

Were you debugging a local install of python, or the default python installed as a part of the OS?

If the latter, it's definitely a footgun but you shouldn't be using it for applications. It's a legacy binary for scripts.

Re: macOS Containers v0.0.1

#258

Post by lgg »

slonopotamus wrote: post #231
kevincox wrote: post #229

Earlier quoted context omitted.

I am also interested in the API boundary. It seems that there are too options: 1. Rely on system call stability. This is like Linux containers but unlike Linux macOS doesn't provide a stable system call API. So this would break when the system updates with a change that modifies the system call API. 2. Install the host libraries into the container at runtime. This should provide as much stability as macOS apps usuall…

> macOS doesn't provide a stable system call API I'm really wondering, do you have any links about macOS syscall stability over versions?

Generally speaking macOS does not guarantee syscall stability, and does not generally guarantee compatibility for any binaries not linked to `libSystem.dylib` (that is the supported ABI boundary)[1]. This has a number of implications, including (but not limited to):

* The most obvious is the commonly mentioned fact that syscalls may change. Here is an example where golang program broke because they were directly using the `gettimeofday()` syscalls[2].

* The interface between the kernel and the dynamic linker (which is required since ABI stability for statically linked executables is not guaranteed) is private and may change between versions. That means if your chroot contains a `dyld` from an OS version that is not the same as the host kernel it may not work.

* The format of the dyld shared cache changes most releases, which means you can't just use the old dyld that matches the host kernel in your chroot because it may not work with the dyld shared cache for the OS you are trying to run in the chroot.

* The system maintains a number of security policies around platform binaries, and those binaries are enumerated as part of the static trust cache[3]. Depending on what you are doing and what permissions it needs you may not be able to even run the system binaries from another release of macOS.

In practice you can often get away with a slight skew (~1 year), but you can rarely get away with skews of more than 2-3 years.

[1]: https://developer.apple.com/library/archive/qa/qa1118/_index...

[2]: https://github.com/golang/go/issues/16606

[3]: https://support.apple.com/guide/security/trust-caches-sec7d3...

Re: macOS Containers v0.0.1

#260

Post by pneumic »

edgyquant wrote: post #248
jmbwell wrote: post #236

Earlier quoted context omitted.

I wish more of those 10k people would help get others off of a package manager that is so fragile and convoluted that updating so often leads to popular things breaking. Things like macports and pkgsrc do things in an arguably much simpler, more unixy way, without the contortions that so often seem to leave homebrew in a bind after routine operations like updating.

I’ve never experienced a broken homebrew and I’ve used Mac for years

Neither have I. My main complaint is that it's slow.
Post reply on HN