Tomcat is not getting started: Permission denied - linux

Question

I am getting below error when trying to start the tomcat using systemd service
systemd[1]: tomcat.service: Failed to execute command: Permission denied
systemd[1]: tomcat.service: Failed at step EXEC spawning /opt/tomcat/bin/startup.sh: Permission denied
Below is my tomcat.service configuration
[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target
[Service]
Type=forking
Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
User=tomcat
Group=tomcat
[Install]
WantedBy=multi-user.target
These are my permission on files in the bin directory
drwxrwx---. 2 tomcat tomcat 4096 Mar 22 05:56 .
drwx------. 9 tomcat tomcat 276 Mar 22 05:58 ..
-rw-r-----. 1 tomcat tomcat 35071 Mar 11 09:33 bootstrap.jar
-rw-r-----. 1 tomcat tomcat 15953 Mar 11 09:33 catalina.bat
-rwxr-x--x. 1 tomcat tomcat 23792 Mar 11 09:33 catalina.sh
-rw-r-----. 1 tomcat tomcat 1664 Mar 11 09:36 catalina-tasks.xml
-rw-r-----. 1 tomcat tomcat 2123 Mar 11 09:33 ciphers.bat
-rwxr-x--x. 1 tomcat tomcat 1997 Mar 11 09:33 ciphers.sh
-rw-r-----. 1 tomcat tomcat 25197 Mar 11 09:33 commons-daemon.jar
-rw-r-----. 1 tomcat tomcat 206895 Mar 11 09:33 commons-daemon-native.tar.gz
-rw-r-----. 1 tomcat tomcat 2040 Mar 11 09:33 configtest.bat
-rwxr-x--x. 1 tomcat tomcat 1922 Mar 11 09:33 configtest.sh
-rwxr-x--x. 1 tomcat tomcat 8675 Mar 11 09:33 daemon.sh
-rw-r-----. 1 tomcat tomcat 2091 Mar 11 09:33 digest.bat
-rwxr-x--x. 1 tomcat tomcat 1965 Mar 11 09:33 digest.sh
-rw-r-----. 1 tomcat tomcat 3606 Mar 11 09:33 makebase.bat
-rwxr-x--x. 1 tomcat tomcat 3382 Mar 11 09:33 makebase.sh
-rw-r-----. 1 tomcat tomcat 3460 Mar 11 09:33 setclasspath.bat
-rwxr-x--x. 1 tomcat tomcat 3708 Mar 11 09:33 setclasspath.sh
-rw-r-----. 1 tomcat tomcat 2020 Mar 11 09:33 shutdown.bat
-rwxr-x--x. 1 tomcat tomcat 1902 Mar 11 09:33 shutdown.sh
-rw-r-----. 1 tomcat tomcat 2022 Mar 11 09:33 startup.bat
-rwxr-x--x. 1 tomcat tomcat 1904 Mar 11 09:33 startup.sh
-rw-r-----. 1 tomcat tomcat 49372 Mar 11 09:33 tomcat-juli.jar
-rw-r-----. 1 tomcat tomcat 419428 Mar 11 09:33 tomcat-native.tar.gz
-rw-r-----. 1 tomcat tomcat 4574 Mar 11 09:33 tool-wrapper.bat
NOTE: I am able to start the tomcat using sudo ./startup.sh command by navigating to bin directory

Answer 1

Can you check your /opt and /opt/bin permissions
Looks like
chmod a+rx /opt /opt/tomcat/ /opt/tomcat/bin
should help

Answer 2

I suppose you followed one of the many copied online tutorials where the tomcat user is made with /opt/tomcat/ as its home directory by using something similar like:
sudo useradd -d /opt/tomcat -s /sbin/nologin tomcat
SELinux is preventing applications from being launched from a home directory, with a message like the following in /var/log/audit/audit.log
type=AVC msg=audit(1614250994.710:33614): avc: denied { execute } for pid=60244 comm="(artup.sh)" name="startup.sh" dev="dm-3" ino=19000615 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
I don't believe the tomcat user needs a home folder, so either remove it from an existing user with:
sudo usermod -d / tomcat
Or create your new user with the following instead:
sudo useradd -M -s /sbin/nologin tomcat
Reset the SELinux properties with the following afterwards:
sudo restorecon -rv /opt/tomcat

Answer 3

I encountered same problem and fix it by restorecon.
I don't know if the reason why the problem happened is same as the original question but I think it depends on how to install tomcat.
In general, we download the tar.gz onto a temp directory and tar xzvf at the temp directory. Next, we move it to /opt or /usr/local. At that time, if we use mv, SELinux context is not changed then permission denied happens. But you can change it by restorecon. If we use cp -R, SELinux context is changed then permission denied does not happen.

Answer 4

In case someone follows the google links to get here, there were three problems in my case that prevented Tomcat 9 (installed from TAR file) from starting on a RHEL 8 system that has CIS recommended security lock-downs on it. I think the DoD STIGs are similar, but not sure. I had the exact same messages in the system journal that the OP did.
First, our security folks went overboard and added the "noexec" option to the mount that the Tomcat was on, which is a separate partition and LVM volume for both security and organizational reasons. I had to modify the mount by removing the "noexec" option in the "/etc/fstab" file, to whit:
Before:
/dev/mapper/vg01-mymount /mymount xfs defaults,nodev,noexec 0 0
After:
/dev/mapper/vg01-mymount /mymount xfs defaults,nodev 0 0
Second, I found they had installed the "fapolicyd" daemon, and that acts like an application allow-listing for execution and access to files. Instead of using the standard method of adding individual binaries to a list in "/etc/fapolicyd/fapolicyd.trust", or creating files in "/etc/fapolicyd/trust.d/" directory, I followed recommendations from this reply on a blog entry here:https://computingforgeeks.com/install-apache-tomcat-9-on-linux-rhel-centos/#comment-7841 . This is the coward's way out, by adding all policy permissions for the tomcat user to access the whole tomcat directory, and depending on file-level permissions to do the security from there:
allow perm=any uid=tomcat gid=tomcat : dir=/mymount/tomcat/
I'm not really sure this will pass scrutiny with any security policies where you work, but it gets the thing running. Individual rules for fapolicyd can be made to run specific files, certain MIME types, read-only on whole directories, etc. The major flaw I found is that the logging from the daemon is less than stellar (or non-existent in my case), and left me scratching my head for a couple days as to what was blocking Tomcat starting. Just knowing fapolicyd is installed is half the battle won.
Third, checking SELinux reports (aureport binary) showed that the systemd binary context of "init_t" did not have permission to execute files in the Tomcat dir because they had the wrong context ("default_t"). Here I only changed the context of the script files in /tomcat/bin/ to "initrc_exec_t", which also may be bad, but it worked without disabling SELinux or doing weird things like compile a new SELinux policy file that allowed that access (i.e. allow init_t to execute default_t files, which seems like it would be much worse). I used a similar command set to the below:
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/startup.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/shutdown.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/catalina.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/setclasspath.sh
semanage fcontext --add --type initrc_exec_t /mymount/tomcat/bin/setenv.sh
restorecon -rv /mymount/tomcat/
I don't know if it needed the last three (catalina.sh, setclasspath.sh, setenv.sh), but I added them to be sure. This fixed my issue with systemd.