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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
