0

I'm using RHEL 8, and I have run into a crazy problem. My user account is unable to open PHP files.

If I have a file, owned by my user, and readable by my user, and I add <?php as the first line, I'm suddenly unable to open, edit, or view the file, even though I have not otherwise changed my permissions. It tells me: cat: test.txt: Operation not permitted

If I look at the file using file, I see the file reported as PHP Script once I add the above line.

It doesn't appear to be an SELinux problem, since setenforce 0 doesn't change the behavior, and audit2allow doesn't see anything.

It's possible this is happening to all script files, but on this server, I only need to use PHP scripts. Help!

Nick2253
  • 141
  • 2
  • 7
  • Can you show the output of `ls -lah `, and `stat --format='%a %n' ` where is one of the affected files? – Ackack Apr 18 '21 at 01:45
  • `-rw-r-----. 1 nick nick 6.2k Apr 17 15:54 test.txt` and `640 test.txt`. Context is `unconfined_u:object_r:user_home_t:s0`. `lsattr` only works with sudo, and shows `-------------------- test.txt`. – Nick2253 Apr 18 '21 at 02:51
  • awesome! both `cat` and `file` read the file, at least beginning, so not exactly the permissions. something weird with terminal formatting maybe? next i would check if problem is present for `root` account, then different user account and then look at syscalls with `strace cat test.txt`. strace will produce a lot of output, but should name failed syscall somewhere – tbielaszewski Apr 20 '21 at 12:27
  • The failed syscall is: `openat(AT_FDCWD, "test.txt", O_RDONLY) = -1 EPERM (Operation not permitted)` When I try with a file that does not have the ` – Nick2253 May 01 '21 at 19:47

1 Answers1

0

I finally found my answer.

As part of a security audit on our web-host servers, the auditor recommended to the administrator that we follow STIG and NIST compliance standards on the servers. We didn't strictly need to follow these standards, but they are highly respected best practices for hardening machines, so it seemed like a worthy goal.

During testing of the standards, no issues were discovered, and the standards were deployed on the servers.

As it turns out fapolicyd is installed as part of these standards, and one of its default policies is to block user access to program files. This didn't impact the web application, but only user editing of those files.

Disabling fapolicyd service allowed the user to edit files. As needed, policies can be added to allow this access all the time.

For more info: http://people.redhat.com/sgrubb/fapolicyd/index.html

Nick2253
  • 141
  • 2
  • 7