Can anyone speak to how the macOS runners on GitHub actions work? It would seem from this post that containers of any kind for macOS are a brand new thing..
macOS Containers v0.0.1
41–50 of 374 posts
Re: macOS Containers v0.0.1
#42https://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.
So I take it you don't use Apple Pay or anything...?
Edit: to be clear for the people who may not know, Apple Pay does not work with SIP disabled. ;P
Re: macOS Containers v0.0.1
#43How 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…
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)
Re: macOS Containers v0.0.1
#44Earlier quoted context omitted.
You're free to disable SIP, so your post makes no sense. It's more akin to locking your front door. Keep it locked if you want the extra protection but feel free to crank the door open if you want the breeze to come in, but knowing that more than the breeze might do so.
Have you ever tried modifying the filesystem a couple levels under /? Last I used a Mac I remember trying to create a new directory in / and writing to /bin (or something like that). I was appalled that Mac doesn't let you do anything other than read-only operations for select paths a few levels under root, and as I remember, there way no way to disable this asinine behavior.
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.
Re: macOS Containers v0.0.1
#45Earlier quoted context omitted.
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.
>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 I've had those with a mac as well.
Re: macOS Containers v0.0.1
#46https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
[flagged]
Seems like all counterarguments to this fact sound like people who aren't competent enough and/or don't understand the basics. There doesn't need to be a higher cognitive load using Linux and security arguments make even less sense.
Re: macOS Containers v0.0.1
#47Earlier quoted context omitted.
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.
>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.
Re: macOS Containers v0.0.1
#48https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
> Disable System Identity [sic] Protection.
Aaand, it's stillborn. Not happening.
Re: macOS Containers v0.0.1
#49Earlier quoted context omitted.
You're free to disable SIP, so your post makes no sense. It's more akin to locking your front door. Keep it locked if you want the extra protection but feel free to crank the door open if you want the breeze to come in, but knowing that more than the breeze might do so.
Have you ever tried modifying the filesystem a couple levels under /? Last I used a Mac I remember trying to create a new directory in / and writing to /bin (or something like that). I was appalled that Mac doesn't let you do anything other than read-only operations for select paths a few levels under root, and as I remember, there way no way to disable this asinine behavior.
lol what?
What's the point of this exercise? Is this some kind of power play against the... operating system?!
Did this prevent you from achieving anything?
In any case, I'm fairly confident if you disable SIP and do a couple extra steps, you can get write access to those.
Re: macOS Containers v0.0.1
#50Earlier quoted context omitted.
Looks like it's open source https://github.com/macOScontainers
Unfortunately, that doesn't answer their question.
yes it does. There’s only one contributor for most of it and you can click to see his profile.
With the source code available and the primary contributor clear, what more could anyone want? Certainly it’s a bit much for one to ask for a security audit they themselves won’t do