SecKeychainGetStatus concurrent access

SecKeychainRef ...;
SecKeychainStatus status;
err = SecKeychainGetStatus(keychain, &status);
if(err == noErr)
{
    if((err = SecKeychainUnlock(keychain, keychainPassword.size(), pass, pass != 0)))
    {
        throw "unable to unlock keychain";
    }
}
else if(err == errSecNoSuchKeychain)
{
    const char* pass = keychainPassword.empty() ? 0 : keychainPassword.c_str();
    if((err = SecKeychainCreate(keychainPath.c_str(), keychainPassword.size(), pass, pass == 0, 0, &keychain)))
    {
        throw "unable to create keychain";
    }
    k.reset(keychain);
}

I use a code like this to Unlock the keychain and create it if not exists, then I have a test case were several servers use the same keychain, and they could run this code concurrently if separate processes.


In such case I see that SecKeychainGetStatus some times fails with error: 100022 description: UNIX[Invalid argument]. Could this be related to concurrent calls to SecKeychainUnlock/SecKeychainCreate on the same keychain?


Any recomendations on how to handle this execenario in wich several servers use a shared keychain, and any of the could unlock/create it ?

Answered by DTS Engineer in 12209022

> Could this be related to concurrent calls to

> SecKeychainUnlock/SecKeychainCreate on the same keychain?


It certainly could be. Normally the only shared keychains on the system (things like the System keychain) are relatively static (they don't come and go, or lock and unlock) so you don't exercise this case.


> Any recomendations on how to handle this execenario in wich several

> servers use a shared keychain, and any of the could unlock/create it ?


I think that once the keychain is created and open you should be OK reading the keychain concurrently. Working on that theory the obvious next step is to move the code that creates and unlocks the keychain to a central service that each of your main servers talks to via XPC.


Share and Enjoy

--

Quinn "The Eskimo!"

Apple Developer Relations, Developer Technical Support, Core OS/Hardware

Accepted Answer

> Could this be related to concurrent calls to

> SecKeychainUnlock/SecKeychainCreate on the same keychain?


It certainly could be. Normally the only shared keychains on the system (things like the System keychain) are relatively static (they don't come and go, or lock and unlock) so you don't exercise this case.


> Any recomendations on how to handle this execenario in wich several

> servers use a shared keychain, and any of the could unlock/create it ?


I think that once the keychain is created and open you should be OK reading the keychain concurrently. Working on that theory the obvious next step is to move the code that creates and unlocks the keychain to a central service that each of your main servers talks to via XPC.


Share and Enjoy

--

Quinn "The Eskimo!"

Apple Developer Relations, Developer Technical Support, Core OS/Hardware

SecKeychainGetStatus concurrent access
 
 
Q