CentOS8 Stream - what is security context in files permissions and how it can affect access?

I did install some of my aspnet core apps on Linux before using CentOS8. This time I used CentOS8-Stream. I dont know if that contributes to the issue.

The facts:

1. I could not make apache use certificates. Everything was as I did before and yet it didnt work. Finally I found some obscure link on the internet which used ls -lrtZ /etc/pki/tls/certs to display security context (I didnt even know it exists). So I simply cp certificate files and it Apache is now fine.

2. However my aspnet app fails with attempt to write a readonly database. I tried the cp trick on it but wont help.. Also no application logs appear

The db file:

-rw-rw-rw-. 1 root root unconfined_u:object_r:httpd_sys_content_t:s0

I dont understand how this security context can override regular chmod-like permissions?? And what to do to fix it? I mean how more explicit permission can get to be rwrwrw ?

Is it some new feature of SELinux? Can I switch it off completely?

Note: 1 and 2 are not related - I just think they have same root cause but nothing in between them. If I access the aspnet app directly without Apache - it has the same error

SELinux is a role based access control system that can control in fine detail what a process is allowed to do. For example, a web server is more secure when it cannot read say /etc/shadow even as root user, nor start a web shell. Security context is fundamental to this system and has been there since the beginning.

SELinux file context is separate thing from UNIX permissions or extended ACLs. All have to allow; yes selinux can deny when basic file permissions would indicate allowed.

Read the RHEL 8 Using SELinux manual and the CentOS wiki page on SELinux. Use the troubleshooting tools there, in particular sealert -a /var/log/audit/audit.log Review any denials around the time of your application problem. Check if any Booleans exist to toggle behavior you want.

Thanks to @John Mahowald I found the right angle for looking at the issue.

The root of the cause is that all my previous VMs are using SELinux permissive mode while the new one (GCP) is running in enforcing mode.

So if you stumble upon strange effects you cant quite explain - see John's links. But use sestatus command first to see which mode your SELinux is set.

P.S. I decided to leave it as permissive as enforcing simply is not viable to maintain. I think this whole SELinux is a white elephant. It has to be replaced