Add options to specify certificates owner/group and permissions #331

Closed
opened 2025-12-29 01:22:55 +01:00 by adam · 1 comment
Owner

Originally created by @mapreri on GitHub (Apr 24, 2018).

I know the usual answer to this kind of questions is to add a hook setting permissions to whatever the admin wants, but to me it seems such a normal situation that I believe dehydrated should support configuring this options in the cof file(s).

It would be best if this was support both in the main configuration file (for the whole $CERTDIR) and for single domains (so it affects only $CERTDIR/$DOMAIN)

I'm imaging this set of variables with these defaults:

CERTOWNER="$DEHYDRATED_USER"
CERTGROUP="$DEHYDRATED_GROUP"
CERTPERM="u=rwX,go="

This should be equal to what dehydrated is doing right now.

Then I as admin who wants to make the certs readable to a whole group I would add e.g.

CERTGROUP=ssl-certs
CERTPERM="ug=rX,o="

(Yes, this proposal doesn't distinguish between public certs and keys, I'm fine with the public certs not being readable by local users shrugs)

Originally created by @mapreri on GitHub (Apr 24, 2018). I know the usual answer to this kind of questions is to add a hook setting permissions to whatever the admin wants, but to me it seems such a normal situation that I believe dehydrated should support configuring this options in the cof file(s). It would be best if this was support both in the main configuration file (for the whole $CERTDIR) and for single domains (so it affects only $CERTDIR/$DOMAIN) I'm imaging this set of variables with these defaults: ``` CERTOWNER="$DEHYDRATED_USER" CERTGROUP="$DEHYDRATED_GROUP" CERTPERM="u=rwX,go=" ``` This should be equal to what dehydrated is doing right now. Then I as admin who wants to make the certs readable to a whole group I would add e.g. ``` CERTGROUP=ssl-certs CERTPERM="ug=rX,o=" ``` (Yes, this proposal doesn't distinguish between public certs and keys, I'm fine with the public certs not being readable by local users *shrugs*)
adam closed this issue 2025-12-29 01:22:55 +01:00
Author
Owner

@lukas2511 commented on GitHub (Apr 25, 2018):

Since a recent commit dehydrated works fine with filesystem ACLs and those can be applied as defaults to a directory. Using those ACLs you can already pre-define who should have access to the files while letting your main dehydrated user (or root) keep full control over the files.

e.g.

setfacl -m u::rwX,g::0,o::0 -m g:dehydrated:rX certs
setfacl -d -m u::rwX,g::0,o::0 -m g:dehydrated:rX certs

would give every user in the dehydrated group read-access to the certificates.

You can also define multiple groups and you can set defaults for certain certificate directory (e.g. setfacl -d -m u::rwX,g::0,o::0 -m g:www-data:rX certs/www.example.com)

So basically everything you need already exists, and if you are using a filesystem that has no ACL support... well... use a hook script ¯\(ツ)

@lukas2511 commented on GitHub (Apr 25, 2018): Since a recent commit dehydrated works fine with filesystem ACLs and those can be applied as defaults to a directory. Using those ACLs you can already pre-define who should have access to the files while letting your main dehydrated user (or root) keep full control over the files. e.g. ``` setfacl -m u::rwX,g::0,o::0 -m g:dehydrated:rX certs setfacl -d -m u::rwX,g::0,o::0 -m g:dehydrated:rX certs ``` would give every user in the `dehydrated` group read-access to the certificates. You can also define multiple groups and you can set defaults for certain certificate directory (e.g. `setfacl -d -m u::rwX,g::0,o::0 -m g:www-data:rX certs/www.example.com`) So basically everything you need already exists, and if you are using a filesystem that has no ACL support... well... use a hook script ¯\\_(ツ)_/¯
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#331