hardMultiple ChoiceObjective-mapped
SELinux Permission Denied on Service Start: Fix with restorecon
A custom application service 'myapp.service' fails to start on a RHEL 8 system with the error: "Failed at step EXEC spawning /usr/local/bin/myapp: Permission denied". The service runs as user 'myapp'. The binary /usr/local/bin/myapp has permissions 755 and is owned by root:root. The user myapp is not in the sudoers. The administrator checks SELinux and finds the binary has the context 'unconfined_u:object_r:usr_t:s0'. The service unit file does not specify any SELinux context. What is the most likely cause of the failure?
Quick Answer
The answer is an incorrect SELinux context on the binary, which must be changed to `bin_t`. When a service fails to start with a "Permission denied" error despite standard Linux permissions being correct (755), SELinux enforcing mode is the likely culprit. The binary's current context `usr_t` is a generic file type that the service's domain (typically `init_t` or a custom domain) is not allowed to execute; executables in `/usr/local/bin` require the `bin_t` type to be launched by system services. On the CompTIA Linux+ XK0-005 exam, this scenario tests your ability to distinguish between DAC (discretionary access control) and MAC (mandatory access control) failures—a common trap is checking file permissions first when SELinux is the real issue. The fix is straightforward: run `restorecon -v /usr/local/bin/myapp` to restore the default `bin_t` context. Memory tip: "If permissions look fine but the service won't start, think SELinux—restorecon is your friend."
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The SELinux context of the binary is incorrect; it should be bin_t.
The error occurs because SELinux is enforcing and the binary has the type 'usr_t', which is not allowed to be executed by the service's domain (probably init_t or custom domain). The correct type for executables in /usr/local/bin is 'bin_t'. The solution is to restore the SELinux context to the default for binaries using `restorecon -v /usr/local/bin/myapp` or changing it to bin_t. Option A is incorrect because permissions allow execution. Option C is unlikely because /usr/local/bin is in PATH. Option D is incorrect as user has execute permission.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The user myapp does not have read access to the binary.
Why it's wrong here
755 grants read and execute to all users.
- ✓
The SELinux context of the binary is incorrect; it should be bin_t.
Why this is correct
The binary has usr_t context, which is not allowed for execution by the service; restoring to bin_t fixes it.
- ✗
The binary is located in a directory that is not in the systemd safe path.
Why it's wrong here
/usr/local/bin is in the default secure path for systemd services.
- ✗
The binary is not executable by myapp due to file permissions.
Why it's wrong here
755 allows others to execute, so user myapp can execute it.
Go deeper
Related to this question
Learn chapter
File Permissions and Ownership
Key term
User
A user is any person, system, or device that interacts with an IT service, resource, or identity system, typically authenticated through credentials and authorized to perform specific actions.
Key term
Service
A service is a software component or system that performs a specific function and is available to be used by other programs or users over a network.
About these practice questions
This XK0-006 question is part of Courseiva's 979-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on XK0-006
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A user reports that a custom application service fails to start with a 'Permission denied' error in the logs. The service runs under the 'appuser' account. Which is the most likely cause and the first step to diagnose?
medium- A.The root password is incorrect; change root password with passwd.
- ✓ B.SELinux is blocking the service; check journalctl for AVC denials and use restorecon or setsebool.
- C.The service binary does not have execute permission for appuser; use chmod +x.
- D.The systemd target is not set to multi-user; run systemctl set-default multi-user.target.
Why B: SELinux enforces mandatory access controls that can block a service from starting even when standard Linux file permissions are correct. The 'Permission denied' error, combined with the service running under a non-root user, strongly suggests SELinux is denying access. Checking journalctl for AVC denials is the standard first diagnostic step to confirm SELinux involvement, followed by using restorecon to fix file context labels or setsebool to adjust SELinux booleans.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This XK0-006 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the XK0-006 exam.