A system administrator is troubleshooting a web application on a hardened Linux server. The application is unable to read its configuration file at /srv/www/config/app.conf. The administrator verified the file has rw-r--r-- permissions and is owned by the correct webapp user and group, under which the application service runs. The server has SELinux enabled and set to "Enforcing" mode. The application logs explicitly show a "Permission denied" error when trying to access /srv/www/config/app.conf.
Which of the following is the MOST likely cause for the file access failure?
The file has an incorrect SELinux security context.
A memory leak in the application is causing it to fail before the file can be read.
The parent directories in the file's path do not have the execute (x) permission bit set for the webapp user.
The webapp user's primary group is misconfigured in /etc/passwd.
The correct answer is that the file has an incorrect SELinux security context. In a Linux environment where SELinux (Security-Enhanced Linux) is in "Enforcing" mode, access is governed by both standard discretionary access control (DAC) permissions (user/group/other) and mandatory access control (MAC) policies. The scenario states that the DAC permissions are correct. Therefore, the "Permission denied" error is most likely caused by the MAC policy. The file's SELinux context (e.g., default_t) may not be one that the application's process context (e.g., httpd_t) is allowed to read. This is a common issue when files are moved from other locations or created in non-standard directories for a service.
Incorrect Answer Explanations:
A memory leak would likely cause the application to crash or hang, generating errors related to memory allocation, not a specific "Permission denied" message.
A misconfigured primary group would likely cause more widespread access issues for the user, and standard file permission checks should have caught it.
Missing execute permissions on a parent directory is a valid cause for access denial, but the prompt implies a thorough check of standard permissions was already completed. Given the explicit mention of SELinux in "Enforcing" mode, its context policy is the most probable culprit.