Why don't my Apps receive unconditional access to Keychain Items specified with -T parameter during creation?

Hi!

I am trying to make a UI Testing target in Xcode for my Application (Client). It works with Keychain items that are created during installation, so in order to mock this installation behavior I am creating the items like this:

security add-generic-password -U -D "[item_kind]" -a "[account]" -l "[label]" -s [service] -w "[value]" -T path/to/UITest-runner.app -T path/to/Client-app.app

However, during UI Testing, the application is still prompted to access or modify the Keychain Items as seen in the bottom half of this screenshot:

These application paths have been obtained by the find terminal command inside DerivedData/.../Build/Products/... so they are the correct paths (which is also proven I guess by the fact that the apps are correctly listed in the ACL window of Keychain Access as seen on the top half of the screenshot).

I also tried using the -A option instead of -T but the result is exactly the same.

Why doesn't this approach work during UI Testing? I am using the same approach in my installation script for the real application installation process with the -T parameters and there is no issue in that case. This issue kills my UI Tests because I am constantly prompted when I want to read of modify the contents of these Keychain Items.

Replies

There’s two potential reasons for for this:

  • If the executable doesn’t have a stable designated requirement (DR), the keychain doesn’t know that version N+1 of the executable is the same as version N. See TN3127 Inside Code Signing: Requirements for more background on DRs.

  • Keychain partitioning, introduced in 10.12, prevents code from team A from accessing items created by code from team B.

One way to bend that last rule is with the security tool, and specifically with its set-CCC-partition-list commands.

Coming back to the big picture, I’m not sure if the above will allow you to get things working. IMO you’d be better off coming up with a better way to mock this. For example, your UI test could launch the app with an argument that points to a property list file where the app reads these credentials from in preference to the keychain.

Share and Enjoy

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

Thank you Quinn for your response!

I just wanted to come back and reply to myself because I have just found the solution - then I saw your reply and it is exactly what was needed :)

I first came to realize that my ACL is actually incorrect deep down because of the partition_list part (security dump-keychain -a path/to/keychain helped me figure this out). It only included the apple-tool: partition (I am creating the keychain items as a pre-run script of the target).

Then I found the set-generic-password-partition-list command, the one you suggest. Changing the partition list to apple-tool:,teamid:[my_team_id] solved the problem and the prompt no longer comes up.