Just a weird random thought inspired by rbash... Normally a restricted shell session would limit a user to their home directory. There'd probably be a ~/bin directory with a bunch of symlinks in it, comprising a highly restricted subset of commands; and the user's PATH would be limited to that, to keep them from breaking out. The rest of the work is done by the restricted shell itself, which prevents the user from running anything with / in its name, or resetting PATH. Now, what if you could do something similiar with arbitrary applications? Code: $ mkdir ~/bin $ ln -s /usr/bin/firefox ~/bin $ PATH=~/bin firefox Hurray, Firefox's PATH is now reduced to include only Firefox. What happens now if someone exploits a hole in Firefox, and can execute arbitrary commands? Code: system("bash"); Oops, bash isn't in PATH, can't do that. Code: system("env PATH=blah blah blah... bash"); Oops, env isn't in PATH, can't do that. Code: system("/usr/bin/bash"); Ouch, pwned. Thus the question here: is there a way to prevent arbitrary applications from launching things with absolute paths, as with a shell in restricted mode? P.S. I realize this is pure userspace stuff, like SRP; a local privilege escalation exploit, run within the compromised program, would tear it to pieces. OTOH, that would mean an attacker would need one more exploit - or, at least, a lot more work - to get at my user account. In my book, anything that raises the difficulty bar for an attacker is probably good.