> One reason to just dlopen() rather than stat() and dlopen() is the race-condition But dlopen() implies code execution all the time, and stat() does not. A

> One reason to just dlopen() rather than stat() and dlopen() is the race-condition But dlopen() implies code execution all the time, and stat() does not. A good way to close this race condition, by the way, is to have a dlopen-by-fd API [FreeBSD has fdlopen], and a single call to open(2) resolves the race condition inherent in referencing the filename multiple times. But to your larger point... It seems there is a crowd that will kneejerk dismiss any criticism as "it's for security". And any implementation bugs (such as introducing massive delays when executing programmatically-generated shell scripts because they need to be hashed and sent to a server, as was an HN headline a while ago) are also justified. I think there needs to be greater skepticism than this about how secure these efforts really makes the system, or if they are just throwing buggy stuff at a wall and applying post hoc justifications.