CODEWITHSUNDEEP
jenkins
CSCMEICOMP
CSCMEICOMP

Reputation: 51

Jenkins - Execute shell - /bin/systemctl: cannot execute: Permission denied

Currently Jenkins shell scripting will not let me run any of the following commands and its driving me bonkers.

I thought initially that it was because tomcat did not have execute permissions on the services mentioned above. So I modified the user property in tomcat.service file and put the file in the /etc/systemd/system/ directory to override the default settings.

Unfortunately, this did not solve the problem. The commands work just fine when I log into the linux machine via PuTTy.

Here is the shell script from jenkins >> Jenkins dashboard > myproject > Configure > Build -Execute Shell:

whoami 

whoami

service csoc-harvester stop

whoami

Here is the log from one of my jobs:

Started by user Casey Christy
Running as SYSTEM
Building in workspace /var/lib/jenkins/workspace/CSOC-Harvester-Test
using credential 0196d60d-2a3a-43a4-9141-4967852d5318
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url http://localhost:8080/gitblit/r/csoc-site.git # timeout=10
Fetching upstream changes from http://localhost:8080/gitblit/r/csoc-site.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials 
 > git fetch --tags --progress http://localhost:8080/gitblit/r/csoc-site.git +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse refs/remotes/origin/Test^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/Test^{commit} # timeout=10
Checking out Revision 8dd49848a7b08965887342ad83c9e8042eda6fbf (refs/remotes/origin/Test)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 8dd49848a7b08965887342ad83c9e8042eda6fbf # timeout=10
Commit message: "Rebuilt War from previous commit"
 > git rev-list --no-walk 8dd49848a7b08965887342ad83c9e8042eda6fbf # timeout=10
[CSOC-Harvester-Test] $ /bin/sh -xe /var/cache/tomcat/temp/jenkins8782561473354276343.sh
+ whoami
root
+ whoami
root
+ service csoc-harvester stop
Redirecting to /bin/systemctl stop csoc-harvester.service
/usr/sbin/service: line 87: /bin/systemctl: Permission denied
/usr/sbin/service: line 87: exec: /bin/systemctl: cannot execute: Permission denied
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Here are the permissions to the services:

-rwxr-xr-x. 1 root root 717688 Aug 16  2018 systemctl
-rwxr-xr-x. 1 root root 778736 Apr 11  2018 ssh
---s--x--x. 1 root root 143248 Jun 27  2018 sudo

When I attempt to add sudo into the mix:

[CSOC-Harvester-Test] $ /bin/sh -xe /var/cache/tomcat/temp/jenkins4737512130372945873.sh
+ whoami
root
+ whoami
root
+ sudo service csoc-harvester stop
/var/cache/tomcat/temp/jenkins4737512130372945873.sh: line 6: sudo: command not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Since command is not found I add the path to the service and I still get:

[CSOC-Harvester-Test] $ /bin/sh -xe /var/cache/tomcat/temp/jenkins9072819074943432808.sh
+ whoami
root
+ whoami
root
+ /usr/bin/sudo service csoc-harvester stop
/var/cache/tomcat/temp/jenkins9072819074943432808.sh: line 6: /usr/bin/sudo: Permission denied
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Upvotes: 0

Views: 2851

Answers (1)

CSCMEICOMP
CSCMEICOMP

Reputation: 51

Alright after much searching I think I figured out the issue. SELinux must have become enabled after I performed an update to the system.

SELinux is a Linux kernel module that provides a framework for configuring mandatory access control for many resources on the system.

I disabled SELINUX and then rebooted my virtual machine (powered down VM, restarted VMware, powered up VM).

Type nano /etc/sysconfig/selinux and edit file to read:

#This file controls the state of SELinux on the system. 
#SELINUX= can take one of these three values: 
#   enforcing - SELinux security policy is enforced
#   permissive - SELinux prints warnings instead of enforcing
#   disabled - No SELinux policy is loaded
SELINUX = disabled 
#SELINUXTYPE = can take one of these two values: 
#   targeted - Targeted processes are protected
#   mls - Multi Level Security protection
SELINUXTYPE=targeted

Instead of disabling SELINUX, another solution that I found involves setting the tomcat_t daemon's domain (security context) to permissive mode. In permissive mode the policy isn't enforced, but logs are generated on the access the policy would normally deny.

Type semanage permissive -a tomcat_t

Upvotes: 1

Related Questions