keychainminder at Login Window

[tburgin]

I am curious to why KeychainMinder is not run at the Login Window?

[russellhancox]

I'd had trouble getting it to work previously. Looking at it again, it should be possible, I just need to make sure it doesn't appear if the user uses the built-in mechanism to reset. Also need to check how it interacts with FDEAutoLogin.

[tburgin]

If you are able to run your UI modally at the Login Window you could get out in front of the ugly Apple built-in mechanism. I think this runs in the HomeDirMechanism. So as long as you put yours before that, you might be okay? By the time Apple's run, the Keychain will not need any attention and it should just pass though.

To run the .app modally you may have to call the app directly with NSTask -waitUntilExit. I am not sure if the launch agent could halt the login process.

Or you could look into initWithWindowNibName from the plugin itself. Then [NSApp runModalForWindow:[windowController window]];

https://github.com/tburgin/PSU_2015/blob/master/VerifyAuthPlugin/Views/Prompt/PromptWindowController.m

This approach would allow you to use the known good new password directly :)

But it does get hairy. You can't use NSApp in a privileged mech and I don't think you can setuid in a non-privileged mech. You would have to do a song and dance with multiple mechs.

Just thinking out loud :+1:

[russellhancox]

I spent quite a while before the first release trying to get a UI working from the plugin (using 3 mechanisms) and had trouble getting it working, particularly on 10.10 with FV2 enabled.

I'd be quite pleased to replace the Apple mechanism as the dialog confuses many users but I don't want to risk breaking login. v1.2 above makes it work after the Apple mechanism for anyone who choose "Continue log-in" and causes the UI to appear with the desktop.

[tburgin]

The approach you take in v1.2 seems like the sanest solution. You have a pretty solid solution. Loads better than what ships.

But how cool would it be to never see Apple's dialog again! If you feel like sharing your 3 mech solution, I can put a fresh pair of eyes on it.

[russellhancox]

I'll see if I still have the 3-mech solution anywhere. IIRC the problems I had were:

1) In some situations the UI wouldn't appear but it was running, so the system would hang waiting for a response. The window is set at screensaver level and has canBecomeVisibleWithoutLogin but still wouldn't appear, particularly during boot-up

2) In other situations the UI would appear but wouldn't accept keyboard input.

I tried doing it the proper way with SFAuthorizationView but that had problem 2 as well. These could just be Yosemite problems that may now be fixed, I'm not sure.

[tburgin]

Walking home now, not near a computer...

I remember being frustrated by these exact same issues when I was researching a keychain solution.

As I recall #2 is a result of calling the UI from the privileged mech. Even if you change the UID, the UI will be disabled 10.9 and below.

1 May be similar to #2. In 10.10 the UI would not show at all if a privileged mech called it...

Sent from my iPhone

On Aug 18, 2015, at 5:14 PM, Russell Hancox notifications@github.com wrote:

I'll see if I still have the 3-mech solution anywhere. IIRC the problems I had were:

1) In some situations the UI wouldn't appear but it was running, so the system would hang waiting for a response. The window is set at screensaver level and has canBecomeVisibleWithoutLogin but still wouldn't appear, particularly during boot-up

2) In other situations the UI would appear but wouldn't accept keyboard input.

I tried doing it the proper way with SFAuthorizationView but that had problem 2 as well. These could just be Yosemite problems that may now be fixed, I'm not sure.

— Reply to this email directly or view it on GitHub.

[russellhancox]

I just tried making a non-privileged GUI mechanism and it won't appear above the screensaver. It works fine when unlocking a prefpane but not for the screensaver. Logs show that the window is definitely loading, it seems like it isn't high enough. I've tried NSScreenSaverWindowLevel + 1, NSScreenSaverWindowLevel -1 and kCGMaximumWindowLevel.

Does your VerifyAuthPlugin work at the screensaver?

[tburgin]

Ah, I overlooked that. I was concentrating on the LoginWindow I forgot about the ScreenSaver unlock. I have not been able to get it to display at the screensaver either.

I know VerifyAuthPlugin launches at the ScreenSaver unlock because you can hear the audio clip. It also responds to the return key that exits the window.

If we could figure out how to display the UI properly there, it would be key. I may burn a dev ticket for this...

It would also solve the Fast User Switching problem. In the FUS environment, something similar happens, but you can see a gradient version of the UI.

Or you could have Keychain Minder launch after the ScreenSaver goes away, like you are currently doing. But when system.login.console invokes the plugin, have it load the UI from the plugin? Thus stopping the Apple prompt.

PS, I didn't have much luck with NameAndPassword either...

Sent from my iPhone

On Aug 18, 2015, at 6:54 PM, Russell Hancox notifications@github.com wrote:

I just tried making a non-privileged GUI mechanism and it won't appear above the screensaver. It works fine when unlocking a prefpane but not for the screensaver. Logs show that the window is definitely loading, it seems like it isn't high enough. I've tried NSScreenSaverWindowLevel + 1, NSScreenSaverWindowLevel -1 and kCGMaximumWindowLevel.

Does your VerifyAuthPlugin work at the screensaver?

— Reply to this email directly or view it on GitHub.

[tburgin]

Posted on the dev forum about loading a UI at the ScreenSaver https://forums.developer.apple.com/message/42776 One can hope.

[russellhancox]

This issue was moved to google/macops-keychainminder#4