-
Notifications
You must be signed in to change notification settings - Fork 28
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
[md:error] (13)Permission denied: AH10056: processing {DOMAIN} #117
Comments
Here is a summary of directory and file permissions:
I changed account.json and account.pem to
So, the remaining question is why were the perms wrong to begin with? |
I believe I found the culprit. In my
I can't remember why but that mask has been there for ages. @icing, can (and should) mod_md break the mask and force file permissions? Or, can (and should) mod_md assign a different owner/group just like it does for the |
Thanks for the detailed report and analysis. Will look at it on Monday. mod_md needs some sort of fix to accomodate for such umask settings, I‘d say.
… Am 16.03.2019 um 07:19 schrieb Jerry Martinez ***@***.***>:
I believe I found the culprit.
In my /etc/init.d/ startup script I have the following line immediately before calling apachectl:
umask 007
I can't remember why but that mask has been there for ages. @icing, can (and should) mod_md break the mask and force file permissions? Or, can (and should) mod_md assign a different owner/group just like it does for the md/challenges and md/staging directories?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
My test suite will not catch this as it does not run as root and httpd only switches users then. I committed a change that hopefully addresses this issue and sets the file permissions explicitly. Are you able to clone the current master here, build and verify easily? I could also apply the change to the Apache subversion tree in case you want to avoid all the new things here. |
Thanks for fixing this! As the readme states, patching mod_ssl is not my cup of tea. I would much rather run mod_md that is bundled with the Apache distro. I am currently running 2.4.38. What version will receive your fix, 2.4.39? Also, what permissions should I set to the existing managed domains? Thanks again! |
…s. We want our non-privilegded apache user to be able to read them. See github issue <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1855777 13f79535-47bb-0310-9956-ffa450edef68
…nt our non-privilegded apache user to be able to read them. See github issue <#117>. *) Merged some default store dir change from trunk. *) Merged unread var removal from trunk.
Made you a v1.1.18 for testing. |
I downloaded 1.1.18, unzipped it on the server and ran the following: Then, the following error was thrown:
A few things to note:
As an alternative, I am willing to recompile Apache 2.4.38 with the new mod_md 1.1.18. Just tell me how. |
The But autoconf/automake is not the lightest of topics. You can just take the *.c and *.h files from |
|
Hmm, assuming you do not want to interrupt you working domains...take a another domain or subdomain and configure the staging environment of Lets Encrypt, like
If you have no staging account yet, this should create a new one with the right permissions. If you have one, move it aside temporarily (or just remove it). A staging account should how in its JSON:
where Hope this helps. |
I followed your directions and it appears the permissions are still not being set correctly. Here is what I did:
Wouldn't it be better to just change the group/owner just as done for |
specified permissions on all files created in md store.
No, the files really belong to the one starting the server and should be readable by everyone. I made v1.1.19 with more permission setting goodness. Could you give this a try? (You can just remove all staging related information in the store and start over) Thanks! |
Good job - that did the trick! Now, what httpd release will this patch be included? |
We are about to tag, I think. So, it will be too late for that. I will bring it into the one after that. |
…g restrictions in spite of umask. Fixes <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1856297 13f79535-47bb-0310-9956-ffa450edef68
*) mod_md: Store permissions are enforced on file creation, enforcing restrictions in spite of umask. Fixes <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1856935 13f79535-47bb-0310-9956-ffa450edef68
---------------------------------------------------------------------------------------------------- * Added MD section to Apache's "server-status" page listing all managed domains and their settings, renewal status and error count. * Fix for #117, explicitly set file permissions to work around umask defaults.
*) mod_md: Store permissions are enforced on file creation, enforcing restrictions in spite of umask. Fixes <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1856935 13f79535-47bb-0310-9956-ffa450edef68
…s. We want our non-privilegded apache user to be able to read them. See github issue <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1855777 13f79535-47bb-0310-9956-ffa450edef68
…g restrictions in spite of umask. Fixes <icing/mod_md#117>. [Stefan Eissing] git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1856297 13f79535-47bb-0310-9956-ffa450edef68
…umask defaults.
…nt our non-privilegded apache user to be able to read them. See github issue <icing#117>. *) Merged some default store dir change from trunk. *) Merged unread var removal from trunk.
specified permissions on all files created in md store.
---------------------------------------------------------------------------------------------------- * Added MD section to Apache's "server-status" page listing all managed domains and their settings, renewal status and error count. * Fix for icing#117, explicitly set file permissions to work around umask defaults.
I have been using mod_md for a few months without issues. I have a handful of managed domains and the first one is up for renewal. Apache is throwing the following error:
[md:error] (13)Permission denied: AH10056: processing {DOMAIN}
I researched this error but found issues where other error messages accompanied this one. This is the only error being thrown. I ran a
LogLevel md:trace1
and the output is below:Any help would be appreciated.
The text was updated successfully, but these errors were encountered: