CODEWITHSUNDEEP
macostomcatkeychainlaunchd
jph
jph

Reputation: 2233

mac security command needs write permissions when run by daemon?

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.

Upvotes: 5

Views: 5812

Answers (4)

Guy Mazouz
Guy Mazouz

Reputation: 438

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.

Upvotes: 0

mumbo
mumbo

Reputation: 1

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

Upvotes: 0

atreat
atreat

Reputation: 4413

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.

Upvotes: 3

Dariusz Aniszewski
Dariusz Aniszewski

Reputation: 457

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.

Upvotes: 4

Related Questions