Open cowwoc opened 10 years ago
Line 261 is invoking sudo echo
which doesn't work as expected. See http://stackoverflow.com/q/84882/14731
I will create a pull request soon to fix this.
I left the warning message for A keychain with the same name already exists
because I didn't want to suppress other warnings the command might output.
Okay, we have the following outstanding warning messages:
security: SecKeychainCreate login.keychain: A keychain with the same name already exists.
triggered by sudo -i -u ${SERVICE_USER} security create-keychain -p ${OSX_KEYCHAIN_PASS} ${OSX_KEYCHAIN}
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.
triggered by KEYSTORE_PASS=
sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh get-password --account=${SERVICE_USER} --service=java_truststore``Security wants to use the "Local Items" keychain.
dialog box triggered by sudo -i -u ${SERVICE_USER} ${SERVICE_HOME}/security.sh set-password --password=${KEYSTORE_PASS} --account=${SERVICE_USER} --service=java_truststore
I'm going to try again to prevent these warning messages, and especially to prevent the pop up triggered by step 3.
I fixed number 1 and 2 but I'm stuck on number 3. It seems "Local Items" was introduced in Mavericks and it cannot be removed or configured: http://apple.stackexchange.com/a/107078
I see the code executing sudo -i -u builds security add-generic-password -U -w ky2lMNs-Jm0L-rfQEVbG -a builds -s java_truststore login.keychain
where ${SERVICE_USER}
is builds
. For some reason, executing this line causes the dialog box (mentioned in number 3) to pop up and it requires me to enter the password of the user running the installer, instead of that belonging to SERVICE_USER
. Can you please investigate this on your end?
I found the culprit!
security.sh
always locks the keychain on exit. It turns out that executing sudo -i -u builds security lock-keychain login.keychain
locks the local user's Local Items
keychain instead of (or maybe in addition to) that of the Jenkins user. I don't know whether this is a bug or a "feature" on Apple's part.
I propose we stop automatically locking and unlocking the keychain in security.sh
and let the calling script explicitly request these operations. If/when Apple fixes this bug, we can always put back this feature.
How would you like to proceed?
I am not willing to leave an unlocked keychain available to an externally controlled service, and your proposed changes do that.
Note that you are attempting to work around issues in the installer alone by modifying the service itself.
The problem is that I can't have security.sh
lock the keychain because I have no way of unlocking it again. Meaning, I have SERVICE_USER
's keychain password (to unlock it) but not that of the local user.
There are only 2 ways I can think of resolving this problem:
I felt that #1 is a better solution. We could always lock the keychain at the end of the installer script. I did not out of fear that if someone runs the installer twice, the second time will fail.
What do you propose we do instead?
@rhwood I'm still waiting for your response :)
Locking someone else's keychain also locks your own keychain. To prove this run the following test:
sudo -i -u <username> security lock-keychain login.keychain
, where <username>
is a second account. Notice (using Keychain Access) that this operation locks your keychain as well.There is no security risk in leaving the keychain unlocked because it gets locked automatically when sudo
ends. To prove this, run the following test:
sudo -i -u <username> security unlock-keychain login.keychain
, where <username>
is a second account.
I get this output when running the script. If it's harmless, please modify the script to avoid the warnings (e.g. check if a file exists before running
chmod
on it). If the warnings are not harmless, let's debug them further.