We develop a custom authorization plugin for the macOS login screen. We use the SFAuthorizationPluginView class to display our plugin's UI overriding the default macOS login screen, as it is done in the NameAndPassword example (https://github.com/antoinebell/NameAndPassword). We experience a heavy lag - both when using our plugin or NameAndPassword plugin - on the UI when we click any of the user's avatar and there is an animation in which the avatar slides into the middle of the screen, and a custom password box is appearing. This lag also comes when we go back to where the user can select another users. (deactivation of the plugin). We use of course the "List of users" login window display mode. Here I want to emphasise the issue with the NameAndPassword example, because the source code is provided for it and it is a small example created originally by Apple. Are you aware of any bugs in the SFAuthorizationPluginView class which blocks the main/UI thread in the above mentioned cases? We use macOS Monterey 12.6, tried both on M1 and Intel based chipset. We tried the NameAndPassword plugin both on physical machine and Parallel's VM. Original behaviour: https://www.icloud.com/iclouddrive/0b2Z87L3GrTDouwg4pjj0vL2g#original_macOS_login_screen_animation The laggy behaviour with the NameAndPassword plugin: https://www.icloud.com/iclouddrive/0d2_GASYjDGaClboAxXjejH6g#NameAndPassword_lag Thanks for the help in advance!

Our team is working on an Authorization Plugin that presents a UI, so it's being run by the securityagent (_securityagent, UID 92, thus being unprivileged). Our plugin is injected right before the "loginwindow:done" in system.login.console, so technically after the user successfully authenticated him/herself to the OS we present our UI. Also by this time the "HomeDirMechanism:login,privileged" has run, so the current user's home directory is mounted. After this we want to save and load items into/from the current user's (login) keychain. We already have a solution, a running daemon which can read/write but only system keychains. We'd prefer (if that is possible of course) to read and write the user's (login) keychains. According to this technote it is possible to change the EUID to the current user's who's logging in with pthread_setugid_np. Even though we tried to change the EUID from our plugin (UID 92) or from our daemon (UID 0) we weren't able to read/write the current user's login keychain. My question: I guess this is the expected behaviour, but is there any conventional workaround for this to be able to read/write current user's login keychains on the login screen or there's nothing we can do and we should go with using a daemon and reading/writing the system keychain. note: one idea would be to create a launchAgent running in context of the currenty logging in user and maybe that can read/write the respective login keychain items. Thanks for the help in advance.