[macOS] LAContext evaluatePolicy failed when users set the password as blank.

Question

Created Oct ’22

Replies 3

Boosts 0

Views 1.5k

Participants 2

Obviously macOS allows to leave the password field blank so users can set the blank password. But in this case LAContext evaluatePolicy never allow authentication with empty password unlike System Settings(System Preferences). And canEvaluatePolicy produces true on macOS Catalina and BigSur. (while macOS Ventura returns false with "Passcode is not set." NSError)

I tested with Intel macOS 11.7 BigSur and M1 macOS 13 Ventura, they work differently but they both failed to authenticate. The detail is as follows:

[Intel / macOS 11.7 BigSur] & [Intel / macOS 10.15.7 Catalina] When evaluatePolicy called, the password window popped up. If I just click 'OK' button, the password window closed and popped up again right away. And clicking 'OK' again produces an error: (ACMContextVerifyPolicyEx returned 0, still requesting 1:1, 3:1, 15:1 (on context 9c1ee373))

And canEvaluatePolicy with LAPolicyDeviceOwnerAuthentication returns true on these environments..

[M1 / macOS 13 Ventura] When evaluatePolicy called, the password window doesn't pop up with an error: (passcode is not set.)

Is this a bug or is there any way that I can figure out this case?

Answered by DTS Engineer in 734086022

Is there any possibility that having an update in the future for canEvaluatePolicy and evaluatePolicy or macOS so they can work the same on macOS 13 and less than macOS 13?

I can’t predict the future, alas. However, I think it’s reasonable to predict future behaviour based on past behaviour, and in recent years Apple has only updated older OS releases to fix security problems.

Unlike evaluatePolicy, with SFAuthorizationView and System Settings (System Preferences), they can just pass the password window with 'OK' button without typing password. Is the different behaviour of evaluatePolicy intended?

SFAuthorizationView uses Authorisation Services, a very different, and much older, subsystem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’22

Is this a bug … ?

The fact that this changed in macOS 13 suggests that the previous behaviour is considered a bug (not surprising given LA’s iOS heritage). However, the macOS 13 behaviour seems reasonable enough given that -canEvaluatePolicy:error: is returning false.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

June-yub OP

Oct ’22

Thanks for your comment. I totally agree with that macOS 13 behaviour seems more reasonable. Now, I got two questions:

Is there any possibility that having an update in the future for canEvaluatePolicy and evaluatePolicy or macOS so they can work the same on macOS 13 and less than macOS 13?
Unlike evaluatePolicy, with SFAuthorizationView and System Settings(System Preferences), they can just pass the password window with 'OK' button without typing password. Is the different behaviour of evaluatePolicy intended?

0

Answer 3

DTS Engineer OP

Apple

Oct ’22

Accepted Answer

Is there any possibility that having an update in the future for canEvaluatePolicy and evaluatePolicy or macOS so they can work the same on macOS 13 and less than macOS 13?

I can’t predict the future, alas. However, I think it’s reasonable to predict future behaviour based on past behaviour, and in recent years Apple has only updated older OS releases to fix security problems.

Unlike evaluatePolicy, with SFAuthorizationView and System Settings (System Preferences), they can just pass the password window with 'OK' button without typing password. Is the different behaviour of evaluatePolicy intended?

SFAuthorizationView uses Authorisation Services, a very different, and much older, subsystem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0