Questions regarding SIP and maybe requesting Apple to release a real Spaces API? #2274
-
|
Hello, because of the recent changes in macOS 14.5 it seems necessary to disable SIP just to move a window to a new space. See this issue: #2240 As far as I understand you need to disable SIP to do in memory modifications of the Dock.App which controls the window server. Would it also be feasible to do an on disk modification and reenabling SIP after the modifications? I'm also curious to understand how Apple prevents you from calling certain functions of SkyLight? While I was thinking about these things I wondered if it made sense to give feedback to Apple at https://www.apple.com/feedback/ or some other place to requet a real public spaces API. I don't think that it will change their minds, but is probably worth I try? I just wonder what you would expect from such an API? What should be the feature set? Does it make sense to have it as part of an extended Accessibility API? I think in a feedback I would apple encourage to offer such an API for security reason (so we don't need deactivaste SIP!) and that it would also be an accessibility feature since we can modify windows and spaces with keybaord shrotcuts. Best regards, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Different security aspects need to be disabled to allow for persistent on disk modification, so that is not a viable solution in my opinion. The SkyLight framework is a client-side IPC interface which communicates with the macOS WindowServer process (using mach messages). Every application has its own connection that it uses, and this connection is used as an authorization measure, deciding which windows you are allowed to modify. Not all functionality is locked behind this "connection_holds_rights_on_window" check, which is what has allowed them to be used (like pre macOS 14.5 for moving windows to spaces). The function itself is not protected, but the target of the function (e.g the window to modify) is protected, so the function results in a no-op, because you are not authorized to modify that window. The Dock.app connection to the WindowServer is flagged as a universal owner for all windows and is allowed to pass that access restriction, which is why we need to partially disable SIP to inject code into the Dock process, so that we can call these functions (to modify arbitrary windows) using the Dock.app connection. I think it is very clear that Apple has no plans for creating public APIs for these kinds of features. I have been contacted before by a couple of people (claiming to be) working at Apple asking for how this works and what APIs/accesses I'd need to be made available for this to work without having to modify SIP settings, but it has resulted in nothing. |
Beta Was this translation helpful? Give feedback.
-
|
The software in the images is https://hex-rays.com/IDA-pro/ |
Beta Was this translation helpful? Give feedback.
Different security aspects need to be disabled to allow for persistent on disk modification, so that is not a viable solution in my opinion.
The SkyLight framework is a client-side IPC interface which communicates with the macOS WindowServer process (using mach messages). Every application has its own connection that it uses, and this connection is used as an authorization measure, deciding which windows you are allowed to modify. Not all functionality is locked behind this "connection_holds_rights_on_window" check, which is what has allowed them to be used (like pre macOS 14.5 for moving windows to spaces). The function itself is not protected, but the target of the function (e.g the win…