You spend half an hour recompiling your app, move the binary to a custom directory in /opt, and fire it up only to get a Permission Denied error that makes no sense. The file permissions are wide open, the user has read access, and yet the kernel is blocking the execution. It is SELinux, and it is usually because the binary lacks the correct security context label required for the new path.

Why context matters more than filesystem permissions

Most people treat SELinux like an annoying secondary layer of permissions. In reality, it works on security contexts, not just owner IDs. If your binary was compiled or moved from a temporary directory, it might carry a generic label like unlabeled_t or bin_t, which causes the policy engine to panic when the binary tries to link against a library in a restricted zone. The kernel isn’t looking at your chmod bits; it is looking at the type field of the extended attribute.

semanage fcontext -a -t bin_t /opt/myapp/bin(/.*)?
restorecon -Rv /opt/myapp/bin

• The -a flag adds the record to the policy database so it survives a relabeling event.
• The (/.*)? regex ensures every file inside the directory gets the inherited label.
• Restorecon is the part that actually applies the change to the disk, which most people forget.

If you are debugging this, stop flipping to permissive mode immediately. Use ausearch to see why the AVC denial actually triggered. Sometimes you moved a library to a weird place, and the binary now needs execmem or execstack access because of how it was built, which a simple label fix won’t solve. Check the logs before you give up and disable the entire subsystem, because that is a mistake you will pay for later when an actual intrusion happens.