Script should create world-readable verification files #32
Conversation
|
The files already is chowned to the user and group of the parent directory, so shouldn't be needed. Update: Saw the other issue you had 👍 |
|
Except that chown (which is not even guaranteed to work if the script is not run as root) does not guarantee correct permissions: it is often advised to have the pages of the webserver be owned by a different uid than the server runs under. This way, a malicious script run under the server uid would not be able to corrupt the pages. So you need world readable files, even with chown. |
|
@samueltardieu Can you please fix it? Thanks. |
|
(don't ask me how I could convert an issue into a pull request, I don't know it myself, this is a side effect of using the hub command-line script to create the pull-request, and this option looks obsolete anyway) :-) |
|
I just ran into this issue for the reason @samueltardieu stated (I run I agree that writing files to I'm a fan of the approach in this patch, although I'd call |
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
|
@Neilpang Does this mean running as a user other than the webroot owner (and root) is an unsupported use case? |
|
@kevinoid |
|
@Neilpang I'm sorry, but I don't understand. You want me to create a new issue with the same name as this issue? If so, why not reopen this one until it is fixed? Alternatively, I could send a PR of the fix that I am using if you prefer. |
|
@kevinoid Yes, if you have PR, please send me. |
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
When acme.sh is run as a non-root user different from the owner of the webroot directory it is unable to change the owner of the files in .well-known to that user, causing permissions errors. Avoid this by making the files world-readable. These files should pose no disclosure risk since they are sent in cleartext during the HTTP Identifier Validation Challenge[1] and may already be exposed by directory enumeration, depending on server settings. AFAIK they should be safe to expose as world-readable in all cases. 1. https://ietf-wg-acme.github.io/acme/#rfc.section.7.2 Fixes acmesh-official#32 Signed-off-by: Kevin Locke <[email protected]>
The script should use a permissive umask (022) in order to create world-readable verification files.
Some would find this debatable, as the key file might be made readable for everyone as well. In this case, a better solution could be to change the mode of
.well-knownand.well-known/acme-challenge(0755 when they are created by the script), and on the verification file in any case (mode 0644).