On 7/21/20 12:22 PM, Emmett Culley via CentOS wrote:
On 7/21/20 9:59 AM, Simon Matter wrote:
On 7/19/20 10:41 PM, Simon Matter via CentOS wrote:
On 7/13/20 6:40 PM, Emmett Culley via CentOS wrote:
I need to set the umask for apache to 002. I've tried every idea I've found on the internet, but nothing make a difference. Most suggest that I put "umask 002" in /etc/sysconfig/httpd, but that doesn't seem to make a difference. Other's suggest adding something to the httpd.service script for systemd. And that doesn't make any difference.
I had a couple sideline emails with Emmett about suexec possibly being the culprit. TL;DR: that's not it.
The apache suexec utility can enforce a umask (typically 022) on CGI and SSI (server-side includes). Taking a look at the source in support/suexec.c, if compiled with AP_SUEXEC_UMASK set to some value, it will set the umask; else there is no umask change. AP_SUEXEC_UMASK is set via ./configure with --with-suexec-umask.
In CentOS 8 httpd-2.4.37-21.module_el8.2.0+382+15b0afa8.src.rpm the httpd.spec for ./configure with suexec-related configuration flags are notably absent of --with-suexec-umask. I also did a prep of the sources and no patches modify the suexec sources in this way.
I may have missed something but it seems to work in my test:
# grep -i umask /proc/<http_worker>/status Umask: 0022
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002
# systemctl edit httpd.service < enter override config >
<reload/restart httpd>
# grep -i umask /proc/<http_worker>/status Umask: 0002
That's what you are looking for, isn't it?
I didn't test to write files but at least the umask on the process is set as it seems.
Regards, Simon
How can I find the value for <http_worker>?
Emmett
W£ith <http_worker> I meant the processes running httpd. Try this:
ps faxu | grep http[d]
This will give you the list of PIDs and the UID running it. First PID is usually run by root and the children are run by user apache.
Regards, Simon
That's what I thought, but didn't see any results. I may have had apache stopped because of system d errors. I did it just now and saw six threads and each show a umask of 0002.
So it looks like the changes I made to systemd config made a difference after all. Since I am still seeing that group write is not getting set it must be the application.
Thanks for helping me to see that.
Emmett
It turns out that apache's umask was getting set as requested via systemd. But still, files were created using 022 mask. I found that by using the same umask.conf file, suggested by other's, in the directory /etc/systemd/system/php-fpm.service.d, set the umask for php as well, and now files created by php apps have group write and setgid set if the directory it is writing is so configured.
umask.conf contains:
[service] UMask=002
Thanks to everyone that responed.
Emmett