Allow installer to prompt for keychain password

[cowwoc]

1. When the code executes:

sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh set-password —password=${SLAVE_TOKEN} —account=${MASTER_USER} —service=\"`rawurlencode "${SLAVE_NODE}"`\"

the command fails with security: SecKeychainUnlock login.keychain: The user name or passphrase you entered is not correct. and pops up a dialog asking me to enter the password.

It's not clear why the script expects the password to be equal to ${SLAVE_TOKEN} which actually corresponds to the Slave's API token on the Jenkins master node (no relation to what is going on on the slave). Any ideas?

2.. Later on, the code executes:

sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh set-password --password=${KEYSTORE_PASS} --account=${SERVICE_USER} --service=java_truststore

The same thing occurs: wrong password, followed by a pop up asking me to enter the password, but all of a sudden I am asked to change the password for keychain "Local Items". Why am I being asked to do this?

[rhwood]

I am guessing that I have a logic failure in the installer somewhere that failed (at some point—if you retesting with an existing account, likely when a change was made to ensure the user's home directory is respected) to retain the password automatically generated for the service account's keychain.

It should be possible to verify that the automatically generated password was accidentally regenerated (when compared to the keychain password) by doing the following as the service user (become the service user with sudo -i -u service_username:

echo ~/Library/Keychains/.keychain_pass
security unlock-keychain -p `echo ~/Library/Keychains/.keychain_pass` login.keychain

If the keychain cannot be unlocked, it means that the password stored in .keychain_pass is incorrect. If you know the keychain password, use it, otherwise it might be best to blow the service account away and run install.sh again.

[cowwoc]

I am testing all of this in a VM so the script is always running for the first time against my pre-existing user. The key here is probably that I am running against an existing user (whereas the script assumes a new user).

1. When you create a new user, does their keychain get the same password as the user's login password?
2. When the script creates a new user, it's not clear what their password is being set to. Is it really a single character *?

I think we can save a lot of time if you reproduce my environment on your side. Can you please create a dummy user using the OSX gui and then try running the script against it? You should run into the same problems.

[cowwoc]

Also, I assume you don't mean literally echo ~/Library/Keychains/.keychain_pass because that just echos the literal string back to me (not the contents of the file).

When I peek in that file I get:

OSX_KEYCHAIN_PASS=4E6arFggc_Os111_TeDo

and if I try unlocking the keychain with 4E6arFggc_Os111_TeDo it fails.

I don't see a point in the script where it was supposed to set the keychain to this password in the first place...

[rhwood]

The reality is that I built this on the assumption that users would want to use the same account that Jenkins, if installed normally on the system, uses.

I see what's going on in your case. install.sh is assuming that the account did not have a login.keychain created for it outside of install.sh's control (at some point). I'll have to think about how I get around that.

The login.keychain (when created by install.sh) gets a 20 character random password. When install.sh creates the login.keychain, it stores that password in .keychain_pass and rereads that file to prevent itself from changing the password if login.keychain already exists.

The password ***** is a deliberately unusable password, preventing the service account from logging into the system, while still allowing sudo -i -u ${SERVICE_USER} to use a shell other than /usr/bin/false.

[cowwoc]

My goal (which may or may not intersect with the goal of this script) is to create a user that is able to run unit tests inside the iOS simulator. While I expect the default installation to be secure (as you've done), I'd like the option to loosen the security (for troubleshooting purposes), allowing inbound password-protected SSH connections and local logins by the administrator (me). This has saved me countless hours in the past (troubleshooting passively through Jenkins is very time consuming).

Do you mind supporting the latter using command-line options? If so, I'll file a separate issue for it.

[rhwood]

The installer should allow an option (—keychain-password?) that will trigger a prompt for a keychain password instead of attempting to automatically generate one.

This will also need to be documented under a wiki page/readme section titled something like Using an Existing Account

I'm not going to support creating a service account with a usable password, as that would be covered by using an existing account.

[cowwoc]

I'm fine with that. So I guess we leave this issue open until you add this feature?

[rhwood]

Yes.

In the meantime, you should be able to set the password in .keychain_pass to whatever you need it to be and then (re)start the service.

On 8 Nov 2013, at 16:38, cowwoc [email protected] wrote:

I'm fine with that. So I guess we leave this issue open until you add this feature?

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

Randall Wood
Alexandria Software
202.683.8604
[email protected]
http://www.alexandriasoftware.com

[cowwoc]

@rhwood

The above pull request adds the --keychain-password command-line argument. If it's empty, we prompt the user for a password. If it contains a value, we use that as the password.

This gets me past the keychain password, but now it's failing on:

sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh set-password --password=${KEYSTORE_PASS} --account=${SERVICE_USER} --service=java_truststore

I am getting the following prompt: security wants to use the "Local items" keychain. And the odd thing is, the "Local items" password belongs to the account running the script, not the Jenkins account. Any idea what is going on?