Why does the 'sysextd' request deactivation without waiting for a user approval request?

I found a big problem. In Monterey, it does not wait for user acceptance requests. In Monterey, the user appears to fail by requesting deactivation before it is approved. Why are you requesting deactivation without waiting for a user approval request? As a result, deactivation fails. Our app is requesting deactivation based on GUI. I already asked through the feedback number below. (Follow-up: 774983090) However, I do not receive the appropriate response and post it to the Developer Forum.

I'll compare it with a BigSur. First, it's BigSur.

Step 1. The log pops up as shown below, and the user approval request is activated.

19:45:39.665971+0900 sysextd upgrading connection to nsxpc

Step 2. If you approve the user, the log as below comes out.

19:45:43.298319+0900 authd Succeeded authorizing right 'com.apple.system-extensions.admin' by client '/System/Library/Frameworks/SystemExtensions.framework/Versions/A/Helpers/sysextd' [1303] for authorization created by '/Applications/AhnLab Solutions/v3mac/V3FltESApp.app' [3986] (0,0) (engine 243)

Step 3. Once approved, a log appears requesting deactivation as shown below and success.

19:45:43.288928+0900 sysextd deactivation request received from: /Applications/AhnLab 
...
19:45:44.349972+0900 sysextd deactivation succeeded for client: /Applications/AhnLab Solutions/v3mac/V3FltESApp.app/Contents/MacOS/V3FltESApp
19:45:44.350649+0900 sysextd client connection (pid 3986) invalidated

However, within Monterey, a deactivation request is made prior to user approval. In other words, the user appears to fail by requesting deactivation before it is approved.

20:05:54.735224+0900 sysextd upgrading connection to nsxpc
20:05:54.741167+0900 sysextd deactivation request received from: /Applications/AhnLab Solutions/v3mac/V3FltESApp.app/Contents/MacOS/V3FltESApp
...
20:05:54.756362+0900 sysextd deactivation request for com.ahnlab.V3FltES failed authorization check, error: Error Domain=OSSystemExtensionErrorDomain Code=13 "(null)"
20:05:54.760648+0900 sysextd deactivation failed for client: /Applications/AhnLab Solutions/v3mac/V3FltESApp.app/Contents/MacOS/V3FltESApp, error: Error Domain=OSSystemExtensionErrorDomain Code=13 "(null)"
...

Even if you subsequently allow a user approval request, the deactivation request has already failed.

20:06:25.244287+0900 authd Succeeded authorizing right 'com.apple.system-extensions.admin' by client '/System/Library/Frameworks/SystemExtensions.framework/Versions/A/Helpers/sysextd' [308] for authorization created by '/Applications/AhnLab Solutions/v3mac/V3FltESApp.app' [2573] (0,0) (engine 39)
20:06:25.250832+0900 sysextd deactivation failed for client: /Applications/AhnLab Solutions/v3mac/V3FltESApp.app/Contents/MacOS/V3FltESApp, error: Error Domain=OSSystemExtensionErrorDomain Code=4 "(null)"

Replies

it does not wait for user acceptance requests. In Monterey, the user appears to fail by requesting deactivation before it is approved. Why are you requesting deactivation without waiting for a user approval request?

I am not able to reproduce this issue that you have described above in macOS Monterey using a container app with standard NSButtons for activating and deactivating a System Extension.

I am able to reproduce a different issue when deactivating a Network System Extension through deactivationRequestForExtension. For example, installing a Network System Extension through a normal container app GUI, and then letting it run for a few seconds, and then attempting to deactivate the System Extension with deactivationRequestForExtension will fail and orphan the System Extension. There are bugs opened for this. If you experience this issue, the workaround right now is to stop the container app and drag the container app into the trash. This will prompt the proper flow to remove the System Extension.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi meaton. Thank you for your answer.

Can I get the bug report number?

And unfortunately, it's still failing in monterey Beta 5.

There is no content related to the current issue in the release notes. Many customers are waiting for the problem of my app to be solved. I need a schedule when this problem can be solved. It's to persuade customers.

If we don't know the exact schedule, should we expect it to be reflected in the next beta? If you need a log to solve the problem, I will send it to you anytime.

Thanks.

Can I get the bug report number?

(r. 81098252) and FB9402318. If you are not the owner of this bug then you will not be able to see this information.

Regarding:

I need a schedule when this problem can be solved

It looks like this issue is under active investigation and a possible fix is scheduled for a later release at some point. Now, whether this fix resolves your problem or not is an entirely different story. There is no way for me to know that this fix solves your problem until this fix lands in a build and you test it. On that note, there is no timeline for when this fix will land in a build so my recommendation to you would be to keep testing the new Beta's as they are released.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
  • Monterey Beta 6 normally becomes uninstall. If the user permits, the logic that authd requests to sysextd seems to have changed. Thanks  meaton.

  • Great news! Thank you for following up on this. If you have not already, please update your bug report with these findings.

Add a Comment

hello, meaton As you say, I will test it whenever a new version comes out.

I can persuade my clients by quoting your answer.

Hopefully it will be analyzed quickly and solved in the next beta version.

Thank you for your answer.