mac security command needs write permissions when run by daemon?
Asked Answered
B

4

5

I'm tasked with moving a Tomcat/Jenkins installation from the deprecated (and now removed in Yosemite) SystemStarter framework to launchd. It launches and runs fine as a "build" user, except for one thing. Part of our build process involves calling the "security" command to manipulate the keychain. This is failing as follows:

security: cert import failed: write permissions error
security: problem decoding

If I ssh into the build machine and launch Tomcat from a command prompt, via bin/startup.sh, then the call to security doesn't complain. It only complains when I launch Tomcat via launchd. My plist looks like this:

<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.apache.tomcat</string>
    <key>UserName</key>
    <string>builduser</string>
    <key>WorkingDirectory</key>
    <string>/Users/builduser</string>
    <key>Program</key>
    <string>/Users/builduser/bin/tomcat.sh</string>
    <key>KeepAlive</key>
    <dict>
        <key>SuccessfulExit</key>
        <true/>
    </dict>
    <key>EnvironmentVariables</key>
    <dict>
        <key>CATALINA_HOME</key>
        <string>/Users/builduser/Tomcat</string>
        <key>CATALINA_OPTS</key>
        <string>-Djava.awt.headless=true</string>
        <key>JAVA_OPTS</key>
        <string>-Xmx1024m -XX:MaxPermSize=512m</string>
    </dict>
</dict>
</plist>

plist is located in /Library/LaunchDaemons and tomcat.sh is just a wrapper that launches tomcat and then waits for the process to die.

Bort answered 20/10, 2014 at 21:8 Comment(0)
T
4

I've just faced similar problem by myself - I was decoding .mobileprovision file using

cmd -D -i <path_to_file>

Everything works locally and over SSH, but executed from Python app was throwing security: cert import failed: write permissions error

I found this walkaround for what seems to be the same issue and they ended up with creating temporary keychain and using it in security command:

cmd -D -k <specific_keychain> -i <path_to_file>

I'm not 100% sure if this is proper solution to this problem, but it certainly works well.

Teresa answered 16/2, 2015 at 9:56 Comment(0)
T
3

I just implemented Dariusz's workaround and it works magic. In my quest for a solution to this issue I also came across a great answer by user joensson over here:

https://mcmap.net/q/205102/-missing-certificates-and-keys-in-the-keychain-while-using-jenkins-hudson-as-continuous-integration-for-ios-and-mac-development

The gist is add these keys to your plist.

<key>SessionCreate</key>
<true/>
<key>UserName</key>
<string>builduser</string>

I see you already have the UserName set, so it'll just be the SessionCreate key.

Trainman answered 1/5, 2015 at 19:46 Comment(0)
B
0

I also encountered this issue, on further inspection, there seemed to be a mixup between which keychain to use when I was on the machine vs running via ssh and also through my application.

Before trying things, run security default-keychain and check that the keychain you expect is the one being used. If it is not, you can pass the correct one through using the -k flag as above in Dariusz's answer. It may be a keychain corruption issue as well, so you can try resetting or fixing the keychain.

Remember there is both ~/Library/Keychains and Library/Keychains

Bors answered 25/10, 2017 at 11:36 Comment(0)
H
0

If you have configuration management working for your keychain (ansible/chef/etc.) Another solution is resetting the keychain/deleting the "corrupted" keychain and working with a new one.

Horseshoe answered 10/8, 2020 at 14:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.