Following Apple's Configuration Profile Preference, we set "authenticate" for "harddisk-internal" on "mount-controls" on "allowed media payload". After user login, we open Disk Utility and select a internal disk and then click mount, it will prompt an authentication dialog that shows "macOS wants to make changes. Enter an administrator's name and password to allow this." It is expected. But as long as we wait for some time on authentication dialog, the disk will be mounted. The authentication is bypassed. Beside, on this situation, the action "read-only" also be ignored. This should be a BUG.

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: 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): ... authorizationhost: [com.apple.Authorization:AuthorizationHost] Plugin [OurPluginName] is privileged: 0 ... authorizationhost: [com.apple.Authorization:AuthorizationHost] Using helper for unprivileged plugin [OurPluginName]:[OurMechanismName]