Closed alepauly closed 4 years ago
Why disable SIP?
It creates a bigger distance between running build scripting on an end user system compared to the Action/Pipeline VMs. In practice I have never had the need to disable SIP, sometimes some scripting needs to be changes. But still...
thanks for the input @jeroenleenarts. At this point it's not set in stone that we'll disable it and we just wanted to get some feedback (rather quickly). The reason to disable it is because it allows for some workflows that don't with it enabled.
We agree that there's a risk with making the CI environment even more different from where the artifacts will eventually be run but want to get a sense of how users feel about it as well. Thanks again.
@alepauly is this related to gaining programmatic access to microphone, location, camera?
Could this be an argument on a per-job basis e.g. disable_sip: true
?
@alepauly is this related to gaining programmatic access to microphone, location, camera?
Could this be an argument on a per-job basis e.g.
disable_sip: true
?
I think different customers need it for different reasons including building drivers, getting more access to certain OS components, and perhaps access devices.
Unfortunately a per-job variable is not possible at this time but it would definitely be ideal.
At this time we're going to hold off on making this change based on feedback from customers in multiple channels. I'll reopen and pin this issue back up if we decide to go forward with it. Thanks all.
I think different customers need it for different reasons including building drivers, getting more access to certain OS components, and perhaps access devices.
Unfortunately a per-job variable is not possible at this time but it would definitely be ideal.
Guessing this would be a wholly-separate macOS environment, e.g. macos-latest-sip-disabled
?
Sorry to hear you’re abandoning this. It could be quite useful for testing iOS apps in a simulator.
We would like to test https://github.com/eficode/robotframework-imagehorizonlibrary and it uses pyautogui for making actions which it does not work due to accessibility settings, I could change that with sqlite (https://apple.stackexchange.com/questions/178313/change-accessibility-setting-on-mac-using-terminal), but as it turns out there is SIP here which is preventing me to do just that.
I build kexts that I would like to kextload, and SIP disabled would certainly help, I would be able to avoid the whole codesign/certificate access in CI.
My use case is trying to launch TestCafe (browser automation) with Safari on OSX and it also fails as it requires automation and screen recording permissions. Since the issue is closed are there any plans for addressing this at all in near future?
Since the issue is closed are there any plans for addressing this at all in near future?
@andrzej-kodify, no plans right now but thanks for the input. We'll continue looking here and if we are able to figure out a way to offer it cost effectively, we will.
@alepauly , a bunch of related customers requests that could be resolved by disabling SIP:
ideally if we could have option to choose image with or without SIP we could test macOS apps in different environments. Another option could be if we can have a command to respond to macOS system prompts, such as allow/deny firewall prompts. Other macOS prompts for user consent could be enable/disable accessibility and other settings you can see in System Preferences -> Security & Privacy -> Privacy. Our automated UI tests are getting stuck at the moment when those prompts popup. Thank you for your support!
If you are stuck waiting, appveyor pushed new images without SIP; https://www.appveyor.com/updates/
Full disclosure - I’m a DevRel at Codemagic CI/CD, focusing on helping the community build for Apple platforms.
We released SIP disabled macOS images with the latest and beta Xcode versions so you can run macOS UI tests without any extra configuration.
I’ve been working on this for quite some time, and it was really frustrating to get it working properly, but I’m happy with what we managed to release. Hopefully, it will be helpful to the community. I wrote a blog post as well in case you are interested in getting started with macOS UI testing.
Links:
Starting from Big Sur, one cannot chroot
on macOS if SIP is enabled. Maybe current issue should be revisited?
Why disable SIP?
It creates a bigger distance between running build scripting on an end user system compared to the Action/Pipeline VMs. In practice I have never had the need to disable SIP, sometimes some scripting needs to be changes. But still...
Try to set DYLD_FALLBACK_LIBRARY_PATH
for a Rust compilation
We would need this for Rust's CI too, as SIP slows down test execution considerably for the Rust compiler test suite.
SIP being on prevents the ability to use TCCutil on GitHub Actions. This tool is used to enabled accessibility access in a non-interactive way. AFAIK there is no way to SSH or VNC to the agent to do this interactively, but even if that was possible, it would not be a solution for CI environment to do that manually. At the moment, I am not aware of a way to control accessibility access on the agents at all. The solutions I found no longer seem to work. I have documented my use-case in #8214.
Interestingly, SIP is disabled on macos-13 runners. See https://github.com/actions/runner-images/issues/8162#issuecomment-1692902373
We're planning on disabling SIP (System Integrity Protection) on Mac OS 10.15 images. The change is planned to take effect during the week of April 13th.
Please let us know of any concerns or questions you may have about this change.
Virtual environments affected