Here's the setup: I let MySQL dump tables to /tmp (they just contain numbers, no real data) for PHP to pick up and process. After this, the temp files are no longer needed, so I delete them with PHP (unlink).

Of course, SELinux does not like this. I can setup /tmp fine for MySQL to read/write, and PHP to read/write from it, but when PHP wants to delete the file MySQL created, it cannot. I thought it might have to do with the 'sticky bit' on /tmp, but that makes no difference.

I can't really find a proper solution for this problem, most solutions address the issue of making directories readable/writable to PHP (or, the httpd user that is), not deleting someone else's files.

BTW: if I turn SELinux off, PHP will delete the files without issue. So it is definitely something I have to change SELinux-wise, but what would be the best approach?

  • What was in the audit log? – Michael Hampton Mar 11 '18 at 19:43
  • 1
    Yes, good question. Just after posting this I had a brainwave: some time ago I did something with audit2allow in order to sort out a different SELinux issue. Fortunately, I could dig this up. I then scanned the audit.log and piped it: grep {offending rule name} /var/log/audit/audit.log | audit2allow -a then after reviewing that (it looked good) created a module: grep {offending rule name} /var/log/audit/audit.log | audit2allow -a -M tmp and added it: semodule -i tmp.pp. It appears all is well now...! I will monitor it for a bit and if it's still good, post this as answer. – kasimir Mar 11 '18 at 19:53
  • 1
    BTW: the audit2allow result was actually very exact in assessing the situation: allow httpd_t mysqld_tmp_t:file unlink; – kasimir Mar 11 '18 at 19:55
  • Also the documentation has more explicit and detailed instructions which you might be interested in reading. – Michael Hampton Mar 11 '18 at 19:57
  • Thanks for the link, quite helpful. I browsed the RH documentation (which is very good), but it's rather vast and I was probably searching the wrong way. – kasimir Mar 11 '18 at 20:13

As per my comment: I solved it by leveraging audit2allow.

  1. Scan /var/log/audit/audit.log for the offending rule (I used the filename of the file MySQL had written)
  2. Pipe the rule to audit2allow and review it: grep {offending rule name} /var/log/audit/audit.log | audit2allow -a
  3. I got allow httpd_t mysqld_tmp_t:file unlink; from step 2, so that looked exactly like what I was after. With that result, I created a new module: grep {offending rule name} /var/log/audit/audit.log | audit2allow -a -M tmp. This generates a file called tmp.pp.
  4. Import the module file: semodule -i tmp.pp

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.