I am attempting to set up gpg preset passphrase caching using the gpg agent so I can automate my file encryption process. In order for the gpg-agent to run and properly cache the passphrase, it seems there needs to be a S.gpg-agent socket located within the ~/.gnupg/ directory that gets generated in the root directory when I set up gpg and gpg-agent.
What I have done (and which seemed to work in the past) is I would start up everything as root and copy over the contents of the /.gnupg directory to my less privileged user and grant permissions to that socket and directory to the user. The commands I ran to start up the gpg-agent daemon and cache passphrase:
gpg-agent --homedir /home/<user>/.gnupg --daemon
/usr/libexec/gpg-preset-passphrase --preset --passphrase <passphrase> <keygrip>
gpg-agent process seems to be running just fine but I get the below error from the second line:
gpg-preset-passphrase: can't connect to `/home/<user>/.gnupg/S.gpg-agent': Connection refused
gpg-preset-passphrase: caching passphrase failed: Input/output error
I have made sure the socket exists in the directory with proper permissions and this process runs as root. It seems that this socket is still inherently tied to root even if I copy and modify permissions. So my questions are
To add, the agent process seems to run just fine for both users but where I get a little hazy is how the gpg-preset-passphrase is using the socket and if its that or the agent that is refusing the connection to S.gpg-agent
I also assume that I don't need to explicitly start the agent but figured I would this so that I could set any values such as the homedir if needed.
It turns out the issue was unrelated to the gpg-agent and gpg-preset-passprhase.
Note: This is not a permanent solution but it did allow me to get past the issue I was facing.
After modifying the /etc/selinux/config and disabling SE Linux, I no longer experienced the permissions issue above. SE Linux is a Linux kernel security module developed by Red Hat (I am currently running this on RHEL7). It seems the next step will likely be to make sure these binaries and packages are allowed access from my user using audit2allow. Bit more information on this here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow