A developer reports that a compiled binary 'app' fails to execute with 'Permission denied' error when run from a mounted directory '/mnt/software'. The binary has execute permissions for all users. What is the most likely cause?
The noexec mount option blocks execution of binaries on that filesystem regardless of their permission bits, producing 'Permission denied'. Since execute permissions are already set for all users, the mount flag is the remaining cause.
Why this answer
The 'noexec' mount option prevents execution of any binary files on the filesystem, regardless of their file permissions. When a filesystem is mounted with 'noexec', the kernel will refuse to execute binaries from that mount point, returning 'Permission denied' even if the binary has execute permissions for all users. This is a common security measure for mounted directories like /mnt/software to prevent unauthorized code execution.
Exam trap
The trap here is that candidates often assume 'Permission denied' always relates to file permissions (chmod) or SELinux, but the LFCS exam tests knowledge of mount options like 'noexec' which silently override file-level permissions at the filesystem level.
How to eliminate wrong answers
Option A is wrong because SELinux blocking execution would typically produce an AVC denial message in the audit log and a different error (e.g., 'Operation not permitted' or 'Permission denied' with a SELinux context mismatch), but the question states the binary has execute permissions for all users, and SELinux would not be the most likely cause without additional context like a targeted policy. Option B is wrong because missing libraries cause a 'cannot open shared object file' or 'No such file or directory' error, not 'Permission denied'. Option D is wrong because a setuid binary owned by a non-root user would still execute (though the setuid bit would be ignored for security reasons), and the error would not be 'Permission denied' unless the binary itself lacks execute permissions, which it does not.