We run RHEL servers with /tmp mounted using noexec for compliance. A certificate-renewal application creates temporary scripts in /tmp and then executes them, so it currently fails. The vendor says changing the application to use another directory is not possible for now. Security has approved temporarily removing noexec, but would prefer a narrower solution where only the service account can execute the files required by this application. I considered ACLs, but directory traversal permissions and newly created files make that impractical. Is there a way to allow execution for just this service, or is the choice effectively limited to enabling or disabling execution on the mount?
5 Answers
If the application can place all of its temporary files in one dedicated directory, another option is to mount a separate filesystem there with exec enabled and restrict access to the service account. That is more manageable than changing permissions on every new file, but it still requires the application to use that directory and does not solve the problem if /tmp is hard-coded.
Remember that noexec is not a complete script-execution security boundary. It prevents direct execution through the filesystem, but an executable interpreter such as bash, Python, or Perl may still read and run a script from /tmp. So bypassing noexec this way may be possible for the service account or other users who can invoke an interpreter. Treat noexec as defense in depth, not as an execution policy.
Before building a workaround, verify whether the software really hard-codes /tmp. Many programs honor TMPDIR or provide a temporary-directory setting. If it truly embeds /tmp, that is a vendor defect worth escalating. An application that creates and executes arbitrary files in a world-writable directory also deserves a security review, especially for unsafe temporary-file handling.
The cleanest workaround is to isolate the application in its own mount namespace or container. With systemd, look at PrivateTmp= and BindPaths=. You can give the service a private /tmp backed by a filesystem mounted with exec, while the host's shared /tmp remains noexec. A container, bubblewrap, or an equivalent namespace setup can do the same thing. Test carefully because PrivateTmp= behavior and filesystem details depend on the service and systemd version.
SELinux or AppArmor can enforce which executable is allowed to run files from that location. You could create a policy for the service domain that permits the required scripts while denying execution elsewhere. This is more work than a mount option and needs proper testing, but it provides the per-service control you are looking for.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures