Originally created by @intelfx on GitHub (Apr 20, 2018).
The hooks mechanism of dehydrated has a significant usability problem: there is no way to execute hooks with higher privileges than dehydrated itself. For example, I do not want dehydrated to run as root (which I hope is understandable), but I need root privileges to deploy the resulting keys.
Locally, I have worked around this with a sort of "playbook" mechanism: I have a catch-all deployment hook that records all its invocations in a text file and after dehydrated is done, a "real" hook is run that reads the text file and executes recorded actions with elevated privileges.
Can we have something similar in dehydrated? Or at least a kind of internal privilege separation when dehydrated starts as root, forks, then the child process drops privileges, performs network operations and communicates back to the parent when a hook needs to be run.
Originally created by @intelfx on GitHub (Apr 20, 2018).
The hooks mechanism of dehydrated has a significant usability problem: there is no way to execute hooks with higher privileges than dehydrated itself. For example, I do not want dehydrated to run as root (which I hope is understandable), but I need root privileges to deploy the resulting keys.
Locally, I have worked around this with a sort of "playbook" mechanism: I have a catch-all deployment hook that records all its invocations in a text file and after dehydrated is done, a "real" hook is run that reads the text file and executes recorded actions with elevated privileges.
Can we have something similar in dehydrated? Or at least a kind of internal privilege separation when dehydrated starts as root, forks, then the child process drops privileges, performs network operations and communicates back to the parent when a hook needs to be run.
Sorry, but real privilege separation in dehydrated is nothing I'm planning to work on.
Most of the tasks would probably work without any root access:
Writing certificate files: Most services start as root anyway, give only dehydrated access to the certificate folder, the service will be able to read the files
Restarting/Reloading services: At least systemd has policykit support for giving users access to certain systemctl controls without direct root access (other init systems may have this as well, never tried)
DNS hooks and serving of challenge files shouldn't be much of a problem as well
For special cases you could always just use sudo in your hook script with special rules allowing only certain commands to be executed as root
@lukas2511 commented on GitHub (Apr 20, 2018):
Sorry, but real privilege separation in dehydrated is nothing I'm planning to work on.
Most of the tasks would probably work without any root access:
- Writing certificate files: Most services start as root anyway, give only dehydrated access to the certificate folder, the service will be able to read the files
- Restarting/Reloading services: At least systemd has policykit support for giving users access to certain systemctl controls without direct root access (other init systems may have this as well, never tried)
- DNS hooks and serving of challenge files shouldn't be much of a problem as well
- For special cases you could always just use sudo in your hook script with special rules allowing only certain commands to be executed as root
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @intelfx on GitHub (Apr 20, 2018).
The hooks mechanism of dehydrated has a significant usability problem: there is no way to execute hooks with higher privileges than dehydrated itself. For example, I do not want dehydrated to run as root (which I hope is understandable), but I need root privileges to deploy the resulting keys.
Locally, I have worked around this with a sort of "playbook" mechanism: I have a catch-all deployment hook that records all its invocations in a text file and after dehydrated is done, a "real" hook is run that reads the text file and executes recorded actions with elevated privileges.
Can we have something similar in dehydrated? Or at least a kind of internal privilege separation when dehydrated starts as root, forks, then the child process drops privileges, performs network operations and communicates back to the parent when a hook needs to be run.
@leonklingele commented on GitHub (Apr 20, 2018):
setuid / setgid could help here, although unsupported for scripts.
@lukas2511 commented on GitHub (Apr 20, 2018):
Sorry, but real privilege separation in dehydrated is nothing I'm planning to work on.
Most of the tasks would probably work without any root access: