On 7/13/20 4:21 PM, Phoenix, Merka 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.

Any suggestion from this list would be appreciated.

Emmett

SystemD does have a directive for UMask in their "unit" scripts under the '[service]' section

See: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#UMask= [ https :// www. freedesktop. org /software/systemd/man/systemd.exec.html#UMask= ] and also: https://man7.org/linux/man-pages/man5/systemd.exec.5.html [ https :// man7. org /linux/man-pages/man5/systemd.exec.5.html ]

Several posts on StackExchange indicate that the name of the directive 'UMask' is case-sensitive, so it must match the first two letters as UPPERcase, the remainder lowercase.

This posting at ServerFault provides the exact steps: https://serverfault.com/questions/924960/how-to-set-umask-for-apache-on-amaz...

[ https :// serverfault. com /questions/924960/how-to-set-umask-for-apache-on-amazon-linux-2-ami ]

Depending on how Apache httpd is called (for example, if there is a wrapper script called instead of an executable), there may be other players in the mix that would influence what the process ends up with for its umask.

Start first with how Apache httpd is called by SystemD, and trace it out to the binary (see if your script(s) call any other scripts). Worst case, you could go the opposite route and have the unit script call a bash script instead of the executable directly, and the bash script can set umask right before it calls the httpd binary.

Cheers!

Simba Engineering

Thanks for the info. I hadn't seen that before nor many of the links. I had seen the suggested systemd fix, but have never been able got them to work. And I've tried many combinations. Still no luck.

There has to be a way to get this done.

Emmett

On 7/15/20 2:39 AM, Gianluca Cecchi wrote:

On Wed, Jul 15, 2020 at 2:39 AM Emmett Culley via CentOS <centos@centos.org mailto:centos@centos.org> wrote:

Thanks for the info.  I hadn't seen that before nor many of the links.  I had seen the suggested systemd fix, but have never been able got them to work. And I've tried many combinations.  Still no luck.

There has to be a way to get this done.

Emmett

Hi, what is the original need? Could it be that you can accomplish the desired effect using ACL on particular directories/files?

Gianluca

Might could, but that seems like overkill for my purposes, as I don't use ACLs anywhere else. I cannot be the only developer that needs apache created files to be managed by a group. The truth is some sites, like wordpress or joomla, can be better managed when a group member can read or write apache created files. Like via SFTP or local FTP.

Today, I have to make all files world writable to update joomla, and that could be better managed by allowing the owning group to access those files. In the case where the client manages the site, I have to log into the server and change the permissions every time they update the site. Or even to update most plugins.

Wprdpress sites are better, but even then, I still sometimes need to set and unset explicit file permissions depending on the plugins installed.

All this would not be an issue if apache created files with a unask of 002. One simple adjustment to the server to allow us to use normal Linux file permissions to manage files.

If I don't find a solution to this I guess I'll have to use your ACL suggestion. It is getting to be pain to manage multiple sites in the current manner.

Surely someone knows how to force apache to use a umask of 002, other than building from source.

Emmett

On 7/15/20 12:21 PM, Leon Fauster via CentOS wrote:

Am 15.07.20 um 20:02 schrieb Emmett Culley via CentOS:

...

On 7/15/20 2:39 AM, Gianluca Cecchi wrote:

...

On Wed, Jul 15, 2020 at 2:39 AM Emmett Culley via CentOS <centos@centos.org mailto:centos@centos.org> wrote:

Thanks for the info.  I hadn't seen that before nor many of the links.  I had seen the suggested systemd fix, but have never been able got them to work. And I've tried many combinations.  Still no luck.

There has to be a way to get this done.

Emmett

Hi, what is the original need? Could it be that you can accomplish the desired effect using ACL on particular directories/files?

Gianluca

Might could, but that seems like overkill for my purposes, as I don't use ACLs anywhere else.  I cannot be the only developer that needs apache created files to be managed by a group.  The truth is some sites, like wordpress or joomla, can be better managed when a group member can read or write apache created files.  Like via SFTP or local FTP.

Today, I have to make all files world writable to update joomla, and that could be better managed by allowing the owning group to access those files.  In the case where the client manages the site, I have to log into the server and change the permissions every time they update the site.  Or even to update most plugins.

This is best addressed in the application.

For example in wordpress you can set

define( 'FS_CHMOD_DIR', ( 0775 & ~ umask() ) ); define( 'FS_CHMOD_FILE', ( 0664 & ~ umask() ) );

...

Wprdpress sites are better, but even then, I still sometimes need to set and unset explicit file permissions depending on the plugins installed.

All this would not be an issue if apache created files with a unask of 002.  One simple adjustment to the server to allow us to use normal Linux file permissions to manage files.

If I don't find a solution to this I guess I'll have to use your ACL suggestion. It is getting to be pain to manage multiple sites in the current manner.

If the application is to dumpy then ACL is your solution. ACL has a default flag that allows setting permissions that gets heritaged. So that files in the future get the right permissions.

...

Surely someone knows how to force apache to use a umask of 002, other than building from source.

Not a best practice.

Can you suggest why allowing apache to create a file that is group writable in a directory that has the gid bit set, and owned by a group designated by the sysadmin, would be a "bad practice"?

Adding the FS_CHMOD* settings to an application is not always possible and should not be necessary given access to setting the UMASK for an application.

The purpose of the UMASK is to allow server owners the ability to make that server perform best for their purposes.

Since no one seems to have an answer to setting the UMASK for apache than l'll have to use ACLs as others have suggested.

Emmett

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

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

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