5

The problem is that I have PHP files that do not work in the browser. I suspect because the user is missing read permissions.

The files are located in a dir called "ajax"

drwxrwxrwx. 2 root root 4096 Sep 13 14:33 ajax

The content of that dir:

-rwxrwxrwx. 1 root root 13199 Sep 13 14:33 getOrderDeliveryDates.php
-rwxrwxrwx. 1 root root 20580 Sep 13 14:33 getParcelShops.php
-rwxrwxrwx. 1 root root  1218 Sep 13 14:33 index.php
-rwxrwxrwx. 1 root root   814 Sep 13 14:33 lang.php
-rwxrwxrwx. 1 root root  6001 Sep 13 14:33 prod_reviews.php

I'm 100% certain logged in as root:

[root@accept: nl (MP-git-branch)] $

doublecheck with command id:

uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

It is driving me nuts.

tried sudo (even though I already am root).

sudo chmod 777 filename

tried chown (even though I already am the owner root).

 sudo root filename

There are no errors or warnings at all.

OS is CentOS 6

sebasth
  • 14,332
  • 4
  • 50
  • 68
Thomas
  • 171
  • 3
  • 12
  • 1
    From the looks of your id command, you have selinux running. This is probably why you cannot make amendments. – Raman Sailopal Sep 13 '17 at 15:17
  • @RamanSailopal Can you explain why and/or how to solve this? – Thomas Sep 13 '17 at 15:18
  • 1
    Is the file located on a non-Unix filesystem (like a shared Windows partition)? – Kusalananda Sep 13 '17 at 15:19
  • A quick fix is disable selinux with "setenforce 0" and then re-run the command before re-enabling with setenforce 1. If you are looking to modify a number of files, you would be better served interrogating your audit files in /etc/audit/audit.log and updating selinux contexts with audit2allow – Raman Sailopal Sep 13 '17 at 15:24
  • Please add to your question the output of running this command in the affected directory - `mount | grep -F "$( df -h . | sed '2s/^.*%//' ) "` – roaima Sep 13 '17 at 15:26
  • What is the permission of directories leading to `ajax`? – ctrl-alt-delor Sep 13 '17 at 15:34
  • @Kusalananda It **was** a vagrant box (origin unknown) but after some time we no longer needed the vagrant/rsync part and we turned in a regular VM running inside windows server. – Thomas Sep 13 '17 at 17:51
  • @roaima CentOS 6 – Thomas Sep 13 '17 at 17:52

1 Answers1

6

CentOS (and other Fedora/RHEL derivatives) enables an additional security mechanism known as SELinux. It applies additional restrictions on most system daemons. These additional restrictions are checked after regular unix permissions.

For non-default configurations you often need to adjust SELinux. Files contain a specific security label, which is used by SELinux to apply the security policy. If your problem only occurs with some files, you need to correct the SELinux labels on the problematic files. Use chcon with --reference= option to copy the label from a file which works to apply the same label on your problematic file(s):

chcon --reference=<path to working file> <path to not working file(s)>

If your files are in non-standard location, you should add a rule in file labeling database. This avoids problems the next time file system is relabeled or restorecon is used. Choose the label appropriately or use the already applied label (check the existing security labels with ls -lZ).

Adding a labeling rule for /path/to/directory and its contents using semanage:

semanage fcontext -a -t httpd_user_rw_content_t '/path/to/directory(/.*)?'

If your files are on different file system, you can use context option for the mount point to apply/override the default labeling.

sebasth
  • 14,332
  • 4
  • 50
  • 68