Suggestion - flag to set challenge file owner/permission

Feature Requests
1

As I was trying to install SSL on a shared hosting server using webroot method, I found that this server would not serve anything that is not owned by the user, searching through the forum found that lots of users faced or facing similar issues.

Following command
./letsencrypt-auto --text --agree-tos --email webmaster@somedomain.com certonly --renew-by-default --webroot --webroot-path /home/someuser/public_html/ -d somedomain.com -d www.somedomain.com

Would work as it is intended to and creates
Folder “.well-known” owned by root
Folder “acme-challenge” owned by the user
Challenge file owned by root.

Now since the challenge file is not owned by the user, webserver won’t serve it and returns 404.

Now, there could be many reasons/scenarios to this behaviour, hence to over come this, my suggestion is to pass a flag for the user and another for file permissions

–user someuser

When this flag is use, all folders and files get created as user or owner is changed to the mentioned user.

Since letsencrypt-auto is already running as root, it should not be difficult to change the owner.

A similar approach can be adopted for file/folder permissions too, if/when/where needed.
–file 0644
–folder 0755

If these values are not passed, letsencrypt-auto should fallback to default values as it is currently doing.

1 Like
2

I too think this could be a valuable feature and would like to see it added.

3

I filed an issue at

4

Thank you for filing an issue! If the Let’s Encrypt team didn’t have time to work on adding this feature, I could give it a shot and submit a patch if I’m successfully if you’d like.

5

That’s not too difficult… Just fork the Let’s Encrypt source, edit, and make a pull request :slight_smile:

Only pull requests on GitHub are accepted, not separate patches, just for you to know :wink:

6

It would be great to see a contribution like this (thanks for your interest, Spork). If prospective contributors don’t have a GitHub account and don’t want one, it might also be possible to submit a patch by e-mail even though there is no formal process in place for this.

7

As a workaround, put the command in a script and have the first line of the script be:

umask 022

It’s what I’ve had to do with mine. Ensures perms that would be applied 700/600 end up being 755/644.