mac security command needs write permissions when run by daemon?

Question

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.

Answer 1

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.

Answer 2

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://stackoverflow.com/a/9482707/1074558

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.