How to share Letsencrypt cert files amonst several daemons having different group name
Clash Royale CLAN TAG#URR8PPP
How to share Letsencrypt cert files amonst several daemons having different group name
Multiple daemon applications would like to access the same TLS certificates (or chain, or private) keys.
And they all run their daemon with different GID and group name.
My attempts at securing the private key in a safe manner, yet sharing it across different daemons (having their own GID) with the following various approaches (and some later nixed) are:
Set file permission to "blaze of glory" chmod a+rwx. This got nixed because it reveals the secret privkey.pem file to the entire filesystem.
chmod a+rwx
Create a new group keys and add nginx, apache, named (or bind), and sftdyn group to the keys group in /etc/group (or using adduser nginx keys). Use new keys group on the PEM files. Then cap PEM files' permission with chmod 0640.
keys
nginx
apache
named
bind
sftdyn
keys
adduser nginx keys
keys
chmod 0640
Use setfacl.
setfacl
Which of 2 or 3 is best to address this thorny issue?
1 Answer
1
System admin side of me believes strongly in "keep it simple" and says to do it via the "keys" group (or ssldaemons or whatever you want to name it - I think group names should describe the membership or purpose if possible) and regular old boring file system permissions.
On the other hand, if you are already using ACLs then using just another ACL rule or three would fit better into your work flow/policy/admin style.
If you aren't using ACLs already, then I wouldn't head down that road - no need to make things excessively complex. Unless of course you need an excuse to management to do it :)
@EgbertS works fine, I use it to control a few other things so in my use case it had to be 2nd-ary groups. And, from a sysadmin side, adding a user's primary group to some user as a secondary group is against the design of the permissions model - it works, but it also removes the ability ot have a file/directory that is private to the first user.
– ivanivan
Sep 10 at 20:22
Unless the file has root:secondgroup and 0750/0640?
– Egbert S
Sep 11 at 0:41
@EgbertS root isn't the only user that may need to keep things private. Think about hte private half of a public/private key pair?
– ivanivan
Sep 11 at 0:57
Hence the
chown root:key <file> notation?– Egbert S
Sep 12 at 20:00
chown root:key <file>
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
Secondary group ID would be okay then?
– Egbert S
Sep 10 at 12:20