SELinux context seems incorrect for java

Question

I ran into an issue with Tomcat failing to start using systemctl start but starting OK when the script was executed from the command line as root. That seemed to point to a permissions problem but in checking the file ownership and group, everything is tomcat:tomcat. And, it used to start just fine and "suddenly" stopped starting with systemctl start (except, there has to be a reason).

I posted that issue here:

Tomcat 9 no longer starting using systemctl but will start manually

I'll be the first to say that even though I have now read way more about SELinux than I wanted to, I am still not 100% sure about how it works, or in this case, would cause issues. Here is what I have found so far and the questions that go with it.

Based on what I read about SELinux, when in Permissive mode, it will audit accesses but it won't prevent access or cause problems. Is that true? In my case sestatus shows: (CENTOS7)

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

Since it is permissive, then it shouldn't affect anything, should it? But sticking with the idea that it might I found the following:

The java executable, in fact ALL executables in /opt/jdk1.8.0_121/bin/ were owned by "10:143" Which gives me an indication that whatever the user was that owned it was deleted or didn't exist (which my be due to an issue at installation). So, I changed the owner to root:root which matches the java executables in a CENTOS8 VM I have. That didn't take care of the problem. So I listed the contexts for the files using the "ll -Z" command. ALL of the executables are unconfined_u:object_r:usr_t:s0. When I checked the CENTOS8 java folder executables, they are system_u:object_r:bin_t:s0 I am reluctant to change anything else about the files until I understand the ramifications better.

So, what I thought was a Tomcat issue, seems to be a permissions issue and specifically an SELinux issue (although I am not sure of that).

So the questions are:

1. Am I heading down the correct path here? Even though the SELinux mode is permissive, the contexts still need to be correctly set?
2. Is there a way to reset the files, short of re-installing java, that can fix the context issues? It seems like restorecon may do this but I don't want to create more issues.
3. The tomcat issues I have don't create much in the way tracing the problem to the root cause. systemctl start causes a "Class not found" error when it starts, which I know is a permission, rather than a classpath issue (remember this starts OK with root just running the script directly rather than systemctl start). But is there a tool or a log I can use to see what is failing in permissions and why? The audit.log doesn't indicate much in the way of issues with tomcat or java.

That's it. I am a bit mystified by the issue but I'd rather just get it fixed, rather than spend more time trying to figure out how it got this way. The fix might point me to the cause in any case.

Answer 1

So, this is self-inflicted as most "mysteries" are. I still cannot account for some of the differences I see when looking into SELinux contexts between the instances but the REAL cause was subtle (to me). Permissions on the {tomcat root}/lib and {tomcat root}/lib/ext had no execute permissions. That may have been due to a jar that was added recently and then needed to be updated by owner and permissions. In any case, the original issue resulted in many trial and error attempts to fix it which complicated matters further.

I discovered the solution by doing a folder by folder, file by file comparison between working and non-working instances. Apparently the new jar and the owner/permission changes were applied to all but the production version.

So yeah, a permissions issue but not an SELinux permission issue.