We are working on a security agent plugin, that works for the "system.login.console" (on security database).
When we enabled our plugin and then login user, the login would fail. We checked the log, we found the authorizationhost core dumped. We also checked the crash file, we found that the core dump occurred when the authorizationhost wanted to create an authorizationhosthelper (by XPC) to produce the privileged mechanism for the "unprivileged" plugins. Please test this case. The following is the call stack:
This issue only occured on Big Sur beta 3 and 4, not on beta 1 and 2 or Catalina.
FYI: We saw that Apple's plugins all were "privileged (1)", our plugins (third-party) were not "privileged (0)", it's decided by the authorizationhost. Apple's plugins didn't need to create an authorizationhosthelper to do privileged mechanisms, so the issue didn't occur on Apple's plugin.
The following log showed for our plugins (third-party):
When we enabled our plugin and then login user, the login would fail. We checked the log, we found the authorizationhost core dumped. We also checked the crash file, we found that the core dump occurred when the authorizationhost wanted to create an authorizationhosthelper (by XPC) to produce the privileged mechanism for the "unprivileged" plugins. Please test this case. The following is the call stack:
Code Block Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libxpc.dylib 0x00007fff6e07f743 _xpc_serializer_append.cold.1 + 92 1 libxpc.dylib 0x00007fff6e05fb3c _xpc_serializer_append + 305 2 libxpc.dylib 0x00007fff6e05fd3f _xpc_string_serialize + 74 3 libxpc.dylib 0x00007fff6e05fc04 _xpc_dictionary_serialize_apply + 190 4 libxpc.dylib 0x00007fff6e05f6dc _xpc_dictionary_apply_node_f + 132 5 libxpc.dylib 0x00007fff6e05f9d6 _xpc_dictionary_serialize + 137 6 libxpc.dylib 0x00007fff6e05f3b1 _xpc_serializer_pack + 542 7 libxpc.dylib 0x00007fff6e063a0f _xpc_connection_pack_message + 114 8 libxpc.dylib 0x00007fff6e0649f7 xpc_connection_send_message + 73 9 com.apple.authorizationhost 0x000000010a9a2212 0x10a995000 + 53778 10 libdispatch.dylib 0x00007fff6dd89727 _dispatch_client_callout + 8 11 libdispatch.dylib 0x00007fff6dd96612 _dispatch_async_and_wait_invoke + 87 12 libdispatch.dylib 0x00007fff6dd89727 _dispatch_client_callout + 8 13 libdispatch.dylib 0x00007fff6dd95ad4 _dispatch_main_queue_callback_4CF + 940 14 com.apple.CoreFoundation 0x00007fff2caae2e9 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 15 com.apple.CoreFoundation 0x00007fff2ca702c8 __CFRunLoopRun + 2731 16 com.apple.CoreFoundation 0x00007fff2ca6f134 CFRunLoopRunSpecific + 563 17 com.apple.Foundation 0x00007fff2f442fd1 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 18 com.apple.Foundation 0x00007fff2f4d13e4 -[NSRunLoop(NSRunLoop) run] + 76 19 com.apple.authorizationhost 0x000000010a9a0ee7 main + 302 20 libdyld.dylib 0x00007fff6dde0851 start + 1
This issue only occured on Big Sur beta 3 and 4, not on beta 1 and 2 or Catalina.
FYI: We saw that Apple's plugins all were "privileged (1)", our plugins (third-party) were not "privileged (0)", it's decided by the authorizationhost. Apple's plugins didn't need to create an authorizationhosthelper to do privileged mechanisms, so the issue didn't occur on Apple's plugin.
The following log showed for our plugins (third-party):
Code Block ... authorizationhost: [com.apple.Authorization:AuthorizationHost] Plugin [OurPluginName] is privileged: 0 ... authorizationhost: [com.apple.Authorization:AuthorizationHost] Using helper for unprivileged plugin [OurPluginName]:[OurMechanismName]
Indeed. But, on the good news front, we think we know what’s going wrong here. I recommend that you continue to test with beta seeds as they are released.Bad news. It has not yet been fixed on Beta 5.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
