Hi, I'm in the process of creating an App + Helper Tool combo application, and depending on the necessity of root privileges, I'm setting up two paths in the app: If root privileges are not necessary, I'm using SMJobSubmit rather directly: var submissionError: Unmanaged<CFError>? let submissionResult = SMJobSubmit(kSMDomainUserLaunchd, plist, nil, &submissionError) where plist contains these items: Label=com.***.redactedApp.redacted, ProgramArguments=[path/to/helper-tool, commandName, commandArg1, commandArg2] RunAtLoad=1, KeepAlive=0 and it works as necessary, and performs the operations. Now, in the case of privilege escalation being necessary, this call becomes a bit more complex: let authorization = SFAuthorization() var authRef: AuthorizationRef? do { try authorization?.obtain(withRight: kSMRightModifySystemDaemons, flags: [.extendRights, .interactionAllowed]) authRef = authorization?.authorizationRef() } catch let error { // Logging error } var submissionError: Unmanaged<CFError>? let submissionResult = SMJobSubmit(kSMDomainSystemLaunchd, plist, authRef, &submissionError) while using the same plist, same executable at the same path, same Label. However, when using the second path, suddenly SMJobSubmit fails: Error Domain=CFErrorDomainLaunchd Code=2 "(null)" Now, naturally I headed over to system logs in Console.app, and this is the weirdest - there is nothing suspicious near the log item I submit with the above error from the main application. The tool is embedded in the Contents/MacOS folder. However, my problem is that anything that I can think of seems to lead to the same thought: it should be a problem in both cases, not just the privileged one. Is there something extra that must be taken care of when using SMJobSubmit with privileged helper tools?

Hi, I have recently noticed a very-very annoying thing in my CI pipeline, that I managed to reproduce locally. Using macOS Sonoma 14.7.1 and Xcode 15.4, running a test target from Terminal, the first run produces this output: $ xcodebuild test -workspace [redacted].xcworkspace -scheme [redacted] -quiet --- xcodebuild: WARNING: Using the first of multiple matching destinations: { platform:macOS, arch:arm64, id:[redacted], name:My Mac } { platform:macOS, arch:x86_64, id:[redacted], name:My Mac } { platform:macOS, name:Any Mac } Testing started Test suite '[redacted]' started on 'My Mac - [redacted] (75944)' Test case '[redacted].[redacted]()' passed on 'My Mac - [redacted] (75944)' (0.001 seconds) Test case '[redacted].[redacted]()' passed on 'My Mac - [redacted] (75944)' (0.001 seconds) 2024-11-29 19:31:02.311 xcodebuild[75908:47784216] [MT] IDETestOperationsObserverDebug: 1.380 elapsed -- Testing started completed. 2024-11-29 19:31:02.311 xcodebuild[75908:47784216] [MT] IDETestOperationsObserverDebug: 0.000 sec, +0.000 sec -- start 2024-11-29 19:31:02.311 xcodebuild[75908:47784216] [MT] IDETestOperationsObserverDebug: 1.380 sec, +1.380 sec -- end so the test actually completes, but the process does not end, because I get a popup that “Terminal.app” would like to access data from other apps. Removing the "App Sandbox" entitlement immediately alleviates this problem, but it would be very silly to do so because of unit tests. This ultimately means that whenever we use a new device or include a new project or test target, this popup comes up. Very undesirable for CI servers (especially if the servers are ephemeral virtual machines created for the current job). Is there a permanent solution that disables this popup for test runs?

Hi, ASCredentialProvider had been almost identically implemented on both iOS and macOS so far, but the ProvidesTextToInsert feature was only added to iOS. It would have been a crucial point to make Credential Providers available in all textfields, without users having to rely on developers correctly setting roles for their Text Fields. It's right now impossible to paste credentials into Notes, or some other non-password text box both in web and desktop apps for example, in a seamless, OS-supported way without abusing Accessibility APIs which are understandably disallowed in Mac App Store apps. Or just pasting an SSH key, or anything. On macOS this has so many possibilities. It could even have a terminal command. It's even more interesting that "Passwords..." is an option in macOS's AutoFill context menu, just like on iOS, however Credential Providers did not gain this feature on macOS, only on iOS. Is this an upcoming feature, or should we find alternatives? Or should I file a feature request? If it's already in the works, it's pointless to file it.

Hi, we are in the process of exploring how to create an installer for our array of apps. We have come to the conclusion that regular .pkg installers produced by pkgbuild and productbuild are unfulfilling of our expectations. [1] Regardless, our installer needs to place files at privileged locations (/Library/Application Support) so we are looking into how to best solve this problem, with the user having the largest clarity on what they are about to do (so no shady "wants to make changes" dialogs) the least steps to do to install these files in the right place (so no targeted NSSavePanel-s) Now, we have done our light reading via some nicely collected posts on the topic (https://forums.developer.apple.com/forums/thread/708765 for example) and the single missing option in the list of privilege escalation models seems to be a one-time privilege escalation from a GUI app. Our reasons for declaring so: AuthorizationExecuteWithPrivileges is long deprecated and we are trying to build a futureproof solution NSAppleScript is just putting up a shady ("wants to make changes") dialog when trying something like this: $ osascript -e "set filePath to \"/Library/Application Support\"" -e "do shell script \"touch \" & the quoted form of filePath & \"/yyy.txt\" with administrator privileges" Is there another way to request a one-time authorization from the admin to perform such a simple operation as copying a file to a protected location? I know it's possible to externalize and internalize Authorization Rights, but they are just an interface to create extra rights and use them as barriers, because they don't actually pass the required right to further operations based on this documentation. Using SMAppService to register a daemon, which has to be manually allowed by the user adds a lot to the complexity of this installation process, and is something we would like to avoid if possible. (And it's also not the right security model if we want to be honest - we don't want ongoing administrator rights and a daemon) Is there something we haven't taken into consideration? [1] preinstall scripts run after the choices are presented during installation and we would need advanced logic (not the limited JavaScript system/files API provided by Installer JS) - plus, the GUI is obviously very limited in a .pkg :(

Hi, I'm writing a sandboxed Daemon that I register from my sandboxed application via SMAppService. The registration is successful, and the daemon is called based on logs. However when I'm trying to save a keychain item into the keychain, I see entries like this in the logs: (Security) SecItemAdd [com.apple.securityd:atomicfile] create /Library/Keychains/System.keychain.sb-1c133873-RPL9wo: Operation not permitted [com.apple.securityd:security_exception] UNIX error exception: 1 [com.apple.securityd:security_exception] CSSM Exception: 100001 UNIX[Operation not permitted] [com.apple.securityd:security_exception] CSSM Exception: 100001 UNIX[Operation not permitted] I'm attempting to create the item with the regular SecItemAdd function call: var query: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrLabel as String: "[redacted string]", kSecAttrAccount as String: "[redacted string]", kSecAttrService as String: "[redacted string]", kSecValueData as String: secretData ] SecItemAdd(query as CFDictionary, nil) I'm guessing this is because the System keychain is outside of the sandbox for the daemon. Is there a way to create items for the System Keychain from a sandboxed daemon?

Hi, we have quite a headache around wanting to transfer one of our applications to a new Apple Developer Organization. The macOS Application is sandboxed and is bundled with a Safari Extension. The two must be in an App Group in order to share data (as per official Apple documentation). Now this also means, according to this documentation from Apple that this App cannot be transferred, because it has made use of App Groups. If I read correctly online, even if we were to remove this entitlement from the Application, we wouldn't be able to transfer it. Is this all there is to know? I find it rather hard to believe there isn't a workaround for this. Is there maybe a way to transfer the Application and the Safari Extension to the new organization at once, together? I don't mind moving the App Group as well. Can a technical support incident be requested for this type of issue? I'm happy to talk this through with someone from Apple if there is a one-by-one basis (maybe a manual transfer with help from Apple) way to solve this. Why this is a problem, you might ask. First and largest problem is the continuous service for our existing subscribers to the premium version of our application. If we can't move the app, we need to recreate it in the new organization with a new bundle id, new subscription items, everything. I haven't found a straightforward way to move these subscriptions over to another app. I thought about creating an Introductory/Promotional offer, only shown to users with subscriptions in old app. But the length of their subscriptions vary, and offers have a fixed with. Is there anything else I haven't looked at? Thanks in advance!