Authorization Plugin not invoked for Fast User Switching (FUS) on Ventura

Question

Created Oct ’22

Replies 8

Boosts 0

Participants 2

The user interface for Fast User Switching on macOS Ventura appears to have changed and our authorization plugin is not being invoked.

Previously FUS (system.login.fus in auth.db) would show our authorization plugin dialog with a “Switch User” button in the surrounding SFAuthorizationPluginView. In Ventura it first shows the login screen with the row of user avatars and then an animation appears as if the corresponding user from the FUS menu has been selected with a password input field. It looks like a normal login but it doesn’t invoke our authorization plugin like logging out and logging back in does.

The other use cases for our authorization plugin continue to work as expected in macOS Ventura:

system.login.console
system.login.screensaver
authenticate

Is there a work around we can use?

I submitted feedback using Apple's Feedback Assistant (FB11705643) a week ago but have yet to receive any response. I believe this is a security issue Apple may want to fix in a software update.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’22

Is this new in the macOS 13.0 final? Or did it show up in one of the betas?

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

0

Answer 2

peter_at_trusona OP

Oct ’22

I noticed it in the Release Candidate last week but suspect it was present in earlier betas.

0

Answer 3

DTS Engineer OP

Apple

Oct ’22

but suspect it was present in earlier betas.

I need to be clear about something here: The authorisation plug-ins mechanism is super brittle. If you’re relying on it, you really (really really!) need to test with new betas as we seed them. This is especially important for major OS releases, but it applies even for software updates.

As to your current issue, I’ve no idea what’s going on there. If you open a DTS tech support incident, I’ll take a proper look at this.

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

0

Answer 4

peter_at_trusona OP

Oct ’22

Thanks! I think I have some idea what's happening. My bigger concern is making Apple aware and whether a fix can be expected. Can open a DTS incident if it helps.

0

Answer 5

DTS Engineer OP

Apple

Nov ’22

My bigger concern is making Apple aware

For that, file a bug report.

Please post your bug number, just for the record

whether a fix can be expected.

I’m not able to offer concrete information about timelines, either here or one-on-one in a DTS incident.

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

0

Answer 6

peter_at_trusona OP

Nov ’22

Thanks for the quick response. I really appreciate the way you monitor the forums. Bug number is FB11705643 filed 2022-10-19. Best regards, - Peter (K1AV)

0

Answer 7

DTS Engineer OP

Apple

Nov ’22

Looking at your bug report, it seems that system.login.fus is no longer a thing. Rather, the system switches to the new session and invokes system.login.console in that context.

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

0

Answer 8

peter_at_trusona OP

Nov ’22

It does look like that except that our authorization plugin is successfully intercepting login requests by modifying the auth.db entry for system.login.console as follows: Replace: loginwindow:login With: TrusonaAuthorizationPlugin:trusonaLogin

I suspect the bug is that the FUS code path is no longer using the system.login.console entry in auth.db. Somehow it is going directly to the login window bypassing the auth.db list of mechanisms for system.login.console. It might be interesting to test with your modified system.login.console.plist and corresponding plugins GUIAuthPlugin.bundle and LoggingAuthPlugin.bundle .

Kind regards, - Peter

0