0

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?

5
  • What was in the audit log? Mar 11, 2018 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, 2018 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, 2018 at 19:55
  • Also the documentation has more explicit and detailed instructions which you might be interested in reading. Mar 11, 2018 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, 2018 at 20:13

1 Answer 1

0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .