How would I solve something like this?
 

Seems like apache/php has no rights to modify any files in admin/scripts (and probably all other 777 directories like cache...

I installed a program / script, and I followed their instructions of what files and folders should be chmod'ed to 777, so everything would work. I am now told that apache / php dont have rights necessary for the program to work (or certain aspects of it).

Can you tell me how would I go about this? How to check what permissions apache / php have, what they should be for the program to work, and how to adjust the settings.

It is a fresh / clean installation of the latest release of CentOS7. I am fairly new to this, so I am not sure how would I go about this.

Edit:

I have SETFACL set on /var/www/html foleder. It looks like Apache / PHP cant get through this (or maybe /var/www) settings in order to do what is needed. I thought that the default settings of both would be ok (Apache Web Server / PHP), but I guess something does not work with this script. I have the newest version of Wordpress installed, and everything works as it should, 100).

Edit:

getfacl /var/www/html gives something like this:

# file: var/www/html
# owner: root
# group: root
user:rwx
user:user_one:rwx
group:r-x
mask:rwx
other:r-x
default:user:rwx
default:user:unser_one:rwx
default:group:r-x
default:mask:rwx
default:other:r-x (this is default[colon]other[colon]r-x)

Like I said, I did chmod -R 777 on all required folders and files (this was recursively), based on the installation instructions. I kind of dont understand what sort of permission settings could be getting in the way... Like I said, Wordpress works 100% fine (newest version).

Looks like an SELinux issue. To confirm this, check if the inaccessible directory is in /var/log/audit/audit.log.
If so, you need to set the SELinux context on this directory tree. This should be possible with restorecon or chcon in your case; search the web for detail (I would look for "httpd selinux" or "httpd restorecon" to start).

Or perhaps somebody else knows what to do without having to look it up.

I also thought it was SELinux related, initially. I switched it to Permissive mode in /etc/sysconfig/selinux, and everything worked. I then run the following commands:

# getsebool -a | grep httpd

These three need to be set to on:

httpd_enable_cgi
httpd_unified
httpd_builtin_scripting

It is not the only solution, but it is the easiest way to solve this at this point. It is possible to configure it on a domain by domain basis too (more advanced).

# setsebool -P httpd_unified on
# nano /etc/sysconfig/selinux - change back to Enforcing mode
# reboot

Everything works...

Thanks.

SELinux uses several different labels to protect apache from vulnerabilities. What you are doing is removing the protections. Making things world rwx allows anyone to delete/replace... and create their own malware server...


Apache directories are labeled with the type httpd_sys_content_t, which allows apache to read it, but nothing else.

If you want apache to write to things they have to be labeled httpd_sys_rw_content_t, but that is a weakness.

If what is being written to are CGI files... not gonna happen. For CGI to be executed by apache they have to be labeled with the type "httpd_sys_script_exec_t" which again is write protected.

The goal is to protect the rest of the system from vulnerabilities. Apache is confined to only what it is allowed to read and write by the system administrator.

https://access.redhat.com/documentat...TP_Server.html

I have a php script installed on domain.com. Not all the features of the program were working correctly, as they were blocked by SELinux in some way. What would be the best way to solve it? Modify it on the domain.com only? Or maybe go down to directories that the script needs?

Modifying the domain doesn't change the confinement.

You would have to go through the base directories required by the PHP script and set them appropriately for the script. Now, files and directories created BY the script within those modified directories should not be a problem - they will inherit the labels from the parent directory.

WHY ? :banghead: WHY ? :banghead:


now you have to not just fix the permissions to the CORRECT ones
but you also has a SELinux context nightmare to fix

this IS fixable but

30 to 50 min to reinstall the os and apache
or
1 to 3 days( or more) to fix
IF "restorecon" can not fix it

try this -- hopefully the system will auto relabel and fix it

set "setenforce=0"
reboot

then set it to
"setenforce=1"
reboot and let THE ENTIRE set up of drives relabel
this might take a full day or more if it is a HUGE raid array
or if it is a tiny 80 gig drive about 30 min to 1 hour