manpreet Best Answer 2 years ago

Problem

Every few weeks, the php session folder of a machine changes to owner apache even though I'm using nginx. This breaks PHP applications, for example phpMyAdmin, with a session_start(): open(SESSION_FILE, O_RDWR) failed: Permission denied (13)-Error.

I can fix it by manually issuing sudo chown -R nginx /var/lib/php/session/

Environment

• Virtual Machine with CentOS Linux release 7.4.1708, yum-cron with automatic security update installation enabled
• EPEL-Repository installed
• nginx version: nginx/1.14.0
• php version: 7.0.29 (PHP-FPM)

Additional Details

• This seems to break every few weeks, however I can't tell when exactly since we do not use this PMA on a daily basis. However, it broke this week, and in /var/log/yum.log I can see that nginx was updated this week: Apr 18 04:35:53 Aktualisiert: nginx.x86_64 1:1.14.0-1.el7_4.ngx
• I can not find any mention of the user apache in my /etc/php.ini.
• While it's broken, the folder permissions are: drwxrwx---. 2 root apache 94 28. Mär 07:49 session

Question

Why would (automatic) nginx-updates change the owner of the php session folder, thus breaking my applications?

manpreet 2 years ago

there are several ways to approach this problem

package search

If a package is suspected of causing some change, inspect the packages to see if any own the file in question; RPM contain a %files section that detail what files a given package is authoritative for. This can be queried for with rpm -ql. For example a brute force to find which package (if any) owns /etc/passwd might look like:

$ rpm -qa | while read p; do rpm -ql $p | grep -q /etc/passwd && echo $p; done
setup-2.8.71-9.el7.noarch

This method however will not find files that are indirectly modified by a package; RPM contain scripts that can carry out arbitrary actions (or call arbitrary other bits of code that carry out the change being search for). These scripts can be listed with rpm -q --scripts and then that code inspected. It may help to limit the search to only those packages recently installed (check the logs for which ones these are) as there may be a lot of code to look through.

kernel debugging

The linux kernel offers various kernel-based debugging facilities that can be instructed to tell you if something touches a given file. With this method suitable code for SystemTap or sysdig or whatever would be setup, and then you would wait for that to tell you what process has modified the file. For example with sysdig if something is modifying a directory you are interested in:

# sysdig "fd.directory contains /var/lib/php"

should show details (which can be configured with the -p flag) on system calls involving that directory. This command will need to be left running somewhere, possibly in a tmux session or as a custom service so that it starts automatically until the offending code can be found. (Also you may need to limit the debug output, as kernel debugging may produce copious amounts of information if the search is too broad and the command left running for long periods of time.)