4

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

rak_6040
  • 65
  • 1
  • 1
  • 6

4 Answers4

4

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
Forage
  • 2,726
  • 2
  • 18
  • 20
2

Can you check your /opt and /opt/bin permissions

Looks like

chmod a+rx /opt /opt/tomcat/ /opt/tomcat/bin

should help

Ôrel
  • 7,044
  • 3
  • 27
  • 46
1

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.

decsa
  • 11
  • 1
0

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.

db_
  • 51
  • 4