Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't pass environment variables when run via sudo #942

Open
haarp opened this issue Aug 4, 2024 · 2 comments
Open

Doesn't pass environment variables when run via sudo #942

haarp opened this issue Aug 4, 2024 · 2 comments

Comments

@haarp
Copy link

haarp commented Aug 4, 2024

Hey!

currently implementing dehydrated into my environment. I'm using lexicon for the dns-01 challenge.

As I'm using DEHYDRATED_USER and DEHYDRATED_GROUP, sudo is used to run the script. However, sudo by default does not pass environment variables. As a result the clear and easy way of running dehydrated+lexicon using env variables as described here (with this hook) does not work.

This can easily be mitigated by having sudo pass env variables. The -E -H options should be added. -E passes env variables, while -H sets a proper HOME (which would be the wrong one from the env vars otherwise)

I've been running it this way for a while now and see no issues. Would you consider making this the default?

Thanks a lot!

@lukas2511
Copy link
Member

I've created a branch with a new config variable DEHYDRATED_SUDO_ENV that should allow this behaviour. Could you please check if that would solve your problem? https://github.com/dehydrated-io/dehydrated/tree/sudo-env

@haarp
Copy link
Author

haarp commented Aug 4, 2024

Hey, thanks for the super quick response! I've thrown 911a822 on top of my dehydrated, added DEHYDRATED_SUDO_ENV=yes to the config and gave it a test with --force --force-validation. It works, thanks a lot!

Tho I wonder if a config variable is really necessary. Generally it's normal to keep the env when dropping privileges, e.g. daemons using setsid/setgid. I'm trying to think of conditions where this env could be problematic. Apart from gross admin incompetence (unrelated secrets stored in env vars being leaked to a malicious hook) I can't think of any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants