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

161–170 of 374 posts

Re: macOS Containers v0.0.1

#161

Post by slonopotamus »

mbreese wrote: post #91
slonopotamus wrote: post #81

Earlier 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.

And that’s a good thing? I’m not sure the benefits of containers would be worth disabling SIP. Maybe for an automated test CI/CD running system (which is probably the main use-case), but not on anything that users would interact with.

> And that’s a good thing?

That's a technical limitation.

Re: macOS Containers v0.0.1

#162

Post by slonopotamus »

pasc1878 wrote: post #150
doctor_eval wrote: post #44

Earlier quoted context omitted.

I say this as someone who has used Unix, MacOS and Linux for most of his long life: not being able to write to /bin and other system directories is a feature and I really don’t understand how anybody in 2023 could see it otherwise. Freedom does not just imply the ability to do the things you want, but also the ability to avoid the things you don’t.

Why 2023 writing to /bin was always a bad idea in 1994 when I first used Unix and would have been so even earlier.

You can just mount it readonly.

Re: macOS Containers v0.0.1

#163

Post by baq »

_joel wrote: post #160
baq wrote: post #111

cries in Asahi Linux macbook is the best laptop there is but macos... can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.

You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.

I mean, I won't be allowed to install it side by side on my work laptop in a million years. GPU acceleration would be nice in a VM if macOS can pass it through, which I've no idea if it can.

Re: macOS Containers v0.0.1

#166

Post by diogenes4 »

smcleod wrote: post #97
highwaylights wrote: post #7

https://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!

Sincerely, why is this your recommendation? What does this protect against and why do you consider it a concern?

Re: macOS Containers v0.0.1

#167

Post by slonopotamus »

_joel wrote: post #151
lloeki wrote: post #113

Earlier quoted context omitted.

> something that I can already do I would be very curious as to how you already run darwin containers. The only alternative is spinning a macOS VM (including relying on macOS CI machines as a remote job executor)

I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM). From an end user perspective there's no real difference, but I don't have to entirely disable SIP just to use it. Something like namespaces or proper jails on darwin would be super cool, but not at the expense of other security measures and chroot-ish outcome imho. Maybe th…

> this doesn't give me anything extra to what using docker would do on macos

You're missing the point. This project DOES use docker.

Re: macOS Containers v0.0.1

#168

Post by [deleted] »

smcleod wrote: post #157
nyanpasu64 wrote: post #129

Earlier quoted context omitted.

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.

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

[deleted]

Re: macOS Containers v0.0.1

#169

Post by lloeki »

_joel wrote: post #151
lloeki wrote: post #113

Earlier quoted context omitted.

> something that I can already do I would be very curious as to how you already run darwin containers. The only alternative is spinning a macOS VM (including relying on macOS CI machines as a remote job executor)

I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM). From an end user perspective there's no real difference, but I don't have to entirely disable SIP just to use it. Something like namespaces or proper jails on darwin would be super cool, but not at the expense of other security measures and chroot-ish outcome imho. Maybe th…

> I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM)

Ah, I understand your angel, in that your use case is to run namespaced processes that achieve some functional purpose irrespective of the underlying kernel/platform, which is totally fair.

> not at the expense of other security measures

Not for me either... that is, not in a host OS, maybe a dedicated VM; I consider this to be as it says on the tin, 0.0.1, a thing that would help bootstrap an ecosystem of containers, which would push towards Apple adding namespaces or jails (oh, hell yeah, JailKit!) to darwin.

Re: macOS Containers v0.0.1

#170

Post by rawbot »

highwaylights wrote: post #21
perryizgr8 wrote: post #15

Earlier quoted context omitted.

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

This kind of makes me wonder why you'd have a Mac at all (I'm sure there are use cases). Wouldn't a Linux device, or Linux running on a Mac suit you better? For me, the security picture is one of the main features of the eco-system even if it's very restrictive - disabling SIP undermines it more or less completely.

Only way to properly develop iOS apps, I'm afraid.

Connecting to a Mac Agent with Visual Studio on Windows gave me nothing but headaches.

Post reply on HN