the authorizationhost was crashed on Big Sur beta 3 and 4

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:
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]


Up vote post of Galen_Chen Down vote post of Galen_Chen
3.6k views
Posted by
Galen_Chen
Reply
Add a Comment

Accepted Reply

Bad news. It has not yet been fixed on Beta 5.

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.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

Please test this case.

If you want macOS Engineering to investigate this, you should file a bug about it. Please include a sysdiagnose taken immediately after the crash. Also, if you can attach a cut down versino of your authorisation plug-in that demonstrates the problem, that’d be super helpful.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
We're running into the same issue with the latest beta. After our Security Agent plugin is installed, any authorisation attempt that involves one of our plugin's mechanisms fails abruptly. Doesn't seem to matter if it's in loginwindow, in an authentication dialog, or when a right is requested in our app code.

I'm not sure the log message mentioned above "privileged (0)" is necessarily, since it also shows up when running the same plugin on Catalina where the issue doesn't reproduce.

In case this helps in any way, going over system logs in the console.app for the com.apple.Authorization subsystem, this is what it looks like on Catalina where everything works:

Code Block 
debug	17:45:04.234527+0300	authorizationhost	XPC connection isAccepting=1 pid=165
debug	17:45:04.234565+0300	authorizationhost	XPC connection init pid=165
debug	17:45:04.234658+0300	authorizationhost	Request: caller is trusted: 1
debug	17:45:04.234776+0300	authorizationhost	Processing request: pid=165 AuthPlugin:auth
debug	17:45:04.234961+0300	authorizationhost	No plugin at path: /System/Library/CoreServices/SecurityAgentPlugins/AuthPlugin.bundle
debug	17:45:04.283174+0300	authorizationhost	Plugin AuthPlugin is privileged: 0
info	17:45:04.283191+0300	authorizationhost	Using helper for unprivileged plugin AuthPlugin:auth
info	17:45:04.294703+0300	authorizationhosthelper	AuthorizationHost helper start
debug	17:45:04.295203+0300	authorizationhosthelper	Main dispatch_semaphore_wait
debug	17:45:04.295301+0300	authorizationhosthelper	XPC connection isAccepting=1 pid=60413
debug	17:45:04.295351+0300	authorizationhosthelper	XPC connection init pid=60413

When running on the latest macOS Big Sur beta (20A5343i) this is what we're seeing:

Code Block 
debug	17:45:02.452914+0300	authorizationhost	XPC connection isAccepting=1 pid=154
debug	17:45:02.452954+0300	authorizationhost	XPC connection init pid=154
debug	17:45:02.453046+0300	authorizationhost	Request: caller is trusted: 1
debug	17:45:02.453119+0300	authorizationhost	Processing request: pid=154 AuthPlugin:auth
debug	17:45:02.453255+0300	authorizationhost	No plugin at path: /System/Library/CoreServices/SecurityAgentPlugins/AuthPlugin.bundle
debug	17:45:02.476737+0300	authorizationhost	Plugin AuthPlugin is privileged: 0
info	17:45:02.476782+0300	authorizationhost	Using helper for unprivileged plugin AuthPlugin:auth
debug	17:45:02.476857+0300	authorizationhost	No plugin at path: /System/Library/CoreServices/SecurityAgentPlugins/AuthPlugin.bundle
debug	17:45:02.479788+0300	authd	agent: finalizing
error	17:45:02.479827+0300	authd	Error creating mechanism agent (engine 433)
debug	17:45:02.479867+0300	authd	engine 433: evaluate mechanisms result -60008
error	17:45:02.479895+0300	authd	Evaluate cancelled or failed -60008 (engine 433)
error	17:45:02.479918+0300	authd	Evaluate returned -60008, returning errAuthorizationInternal (engine 433)


Posted by
shilgapira
Up vote reply of shilgapira Down vote reply of shilgapira
Add a Comment
@eskimo,
Thanks for replying.
I've filed a bug for this issue, the bug number is FB8198302 on Feedback Assistant, and I also provided a cut-down version of our authorization plugin on there. Please investigate this issue. Thanks.

@shilgapira,
Yes, we encountered the same problem, and the logs are also similar.
Posted by
Galen_Chen
Up vote reply of Galen_Chen Down vote reply of Galen_Chen
Add a Comment
I've also opened a bug report, FB8351241 on Feedback Assistant.
Posted by
shilgapira
Up vote reply of shilgapira Down vote reply of shilgapira
Add a Comment
@eskimo We've opened a radar on the same topic, FB8310522.

We see the same two points that lead to the failure.

  1. The mismatching for a privileged mech as non-privileged.

  2. The new helper that tries to run the mech thinks it's on Tiger still and only looks in /System.

I included logs for regression testing back to macOS BS B1, a fresh copy of NullAuthPlugin as a reduced test case, and client seat impact data.

Just adding us to the dogpile.

Posted by
NoMAD-Dev
Up vote reply of NoMAD-Dev Down vote reply of NoMAD-Dev
Add a Comment

The new helper that tries to run the mech thinks it's on Tiger still and only looks in /System.

Burn!


Unfortunately I don’t have any answers here. I checked on your bugs and they’ve all landed in the right place, so at this point it’s up to macOS Engineering to investigate.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
Bad news. It has not yet been fixed on Beta 5.
Posted by
Galen_Chen
Up vote reply of Galen_Chen Down vote reply of Galen_Chen
Add a Comment

Bad news. It has not yet been fixed on Beta 5.

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.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Indeed.

@eskimo, thanks for replying.
Hope it can be fixed on Beta 6. Our products were stuck here.
Posted by
Galen_Chen
Up vote reply of Galen_Chen Down vote reply of Galen_Chen
Add a Comment
Good news!
This issue has been fixed on Beta 6.
Posted by
Galen_Chen
Up vote reply of Galen_Chen Down vote reply of Galen_Chen
Add a Comment
This crash is indeed fixed in Beta 6. However the login screen froze if I used the SFAuthorizationPluginView sample "NameAndPassword". I followed the steps described in "SFAUTHORIZATIONPLUGINVIEW INTRODUCTION" from Antoine Bellanger. (Somehow I couldn't add the link here, due to the error "this URL can't be included in your post".)

Can anyone confirm that?
Posted by
XiaoLiu_Apple
Up vote reply of XiaoLiu_Apple Down vote reply of XiaoLiu_Apple
Add a Comment

This crash is indeed fixed in Beta 6. However the login screen froze

I tested Beta 6 and noticed the same issue.
The crash is definitely fixed, but authentication is stuck for "system.login.console" and "system.login.fus" rights with custom plug-ins (I tried three: our own, NameAndPassword and Apple's QAuthPlugins-3.0).
What is interesting authentication with a custom plug-in works properly for the rights: "authenticate", "system.restart", "system.shutdown".

Then I checked the logs and noticed that "loginwindow:done" never get called after successful call "loginwindow:success". Going further I noticed the error in SecurityAgent: "SecurityAgent Unable to get the user using a name, the user controller is not running".

Code Block 
default	17:25:21.191134+0300	authd	engine 57: running mechanism builtin:reset-password,privileged (4 of 8)
default	17:25:21.192956+0300	authd	engine 57: running mechanism builtin:auto-login,privileged (5 of 8)
default	17:25:21.194552+0300	authd	engine 57: running mechanism builtin:authenticate-nocred,privileged (6 of 8)
default	17:25:21.486648+0300	authd	engine 57: running mechanism loginwindow:success (7 of 8)
default	17:25:21.487188+0300	SecurityAgent	loginwindow:success is being invoked
default	17:25:21.488545+0300	SecurityAgent	nw_path_evaluator_start [8BCFEEBB-7E84-4759-8096-5D3197CE82A9 Hostname#74cc1d15:0 generic, indefinite]
	path: satisfied (Path is satisfied), interface: en0, ipv4, dns
default	17:25:21.488821+0300	mDNSResponder	[R536] getaddrinfo start -- flags: 0xC000D000, ifindex: 0, protocols: 0, hostname: <mask.hash: 'sjCIe59+OqYjy9AXN1miLA=='>, options: {}, client pid: 954 (SecurityAgent)
default	17:25:21.489845+0300	SecurityAgent	The link monitor has been started
default	17:25:21.491861+0300	mDNSResponder	[R536] getaddrinfo stop -- hostname: <mask.hash: 'sjCIe59+OqYjy9AXN1miLA=='>, client pid: 954 (SecurityAgent)
default	17:25:21.492181+0300	SecurityAgent	Unable to get the user using a name, the user controller is not running

@eskimo, Is that a known bug? Any hope to get the fix in the release build of macOS 11?
Unfortunately, I didn't manage to find a workaround.





Posted by
Lex_A
Up vote reply of Lex_A Down vote reply of Lex_A
Add a Comment
We too see several problems with the authorization plugin:
1) a custom UI deriving from SFAuthorizationPluginView doesn't resize, but is constrained to stay in the 31 pixels that are normally used by the password field shown by the loginwindow
2) when the plugin uses SetResult to make the authentication process advance, nothing happens; I also made an experiment with a custom plugin that immediately calls SetResult in the MechanismInvoke, and the boot is left stuck at 25%. The syslog shows a message "loginwindow[120] <Notice>: There is still an active connection" that hints that the boot thinks something is still working.
Posted by
ampm
Up vote reply of ampm Down vote reply of ampm
Add a Comment

We too see several problems with the authorization plugin

These are separate problems and I encourage you to report them as such.

Please post your bug numbers, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
Here are the feedbacks that I've reported: FB8642358 (stuck on Login Window), FB8690483 (stuck while switching the user from the FUS menu)
Posted by
Lex_A
Up vote reply of Lex_A Down vote reply of Lex_A
Add a Comment