File Access In Apache 2.4

Home » CentOS » File Access In Apache 2.4
CentOS 6 Comments

Folks

I’m having file-access problems in Apache 2.4 under CentOS 7. In particular:

– I have a file that’s readable to every user and every application,
(writeable by only one user), but my CGI scripts cannot read it.

– Some of my CGI scripts need temporary storage for some files. They are, for example, some internal log files, tnat get cleaned up over time, but I want to be able to look at them (as root). Where would you suggest they be placed? I’ve tried /tmp/my_private_files/, and
/var/tmp/my_private_files/, but Apache fails to find even the directory.

Any suggestions?

PS: CentOS 6 had no such problems, and the file locations worked just fine.

David

6 thoughts on - File Access In Apache 2.4

  • Hi David,

    in the /usr/lib/systemd/system/httpd.service file change PrivateTmp=true to PrivateTmp

  • Please don’t modifications in /usr/lib/systemd/system/. System updates will overwrite your changes.

    official way is to copy the unit file to /etc/systemd/system and edit this copy.

    best regards Ulf

  • that’s one way to do it. It has the disadvantage of overriding *all* settings in the vendor-supplied unit files, which may be changed or extended in later releases. I prefer the other supported way (see <https://www.freedesktop.org/software/systemd/man/systemd.unit.html>):

    1. Create a directory named after the unit in /etc/systemd/system, /etc/systemd/system/httpd.service.d/

    2. Create an override file within that directory, for instance private-tmp.conf, with the following contents:

    [Service]
    PrivateTmp=false

    3. Run “systemd daemon-reload” and “systemd restart httpd”

    You can verify that the override file has been loaded with

    This will override only the setting you want to override and still survive updates.

  • Hi Gordon,

    … which is a nice way of doing it quickly, indeed. Thanks for the hint, I didn’t know that command.

    However there is one disadvantage: All changes go into a file named ‘override.conf’, and if one wants to separate them it’s still necessary to know where the configuration change is actually stored.

    I do a lot of stuff with tools like Ansible these days and have made it a custom to keep separate configuration changes in separate files (and ‘systemctl edit …’ wouldn’t work well for that purpose anyway).

    Cheers,

    Peter.