If you link your executable to a library that references a symbol defined in your executable, that symbol will be added to the executable's dynamic symbol table.

It is the case when a library already uses dlopen in unusual code paths, but we want to make sure that code paths won't work.

The examples are some authentication plugins.

all they have to do to beat your dlopen blocker is link against libdl statically

one extra argument to the linker when they compile their plugin

I think p is just trying to prevent people from being shot in the foot as opposed to preventing malicious users ie hackers.

You're not supposed to go to such lengths to stop people from shooting themselves in the foot, because when you do, you also stop people from doing clever things.

I don't want my authentication library to do clever things.

Then you don't have to make yours do so. But if other sysadmins disagree, they should be able to make theirs do so.

im talking from the point of view as the user of the software.

The same applies. If you don't want it to do clever stuff on your computer, then just configure it not to do so. Don't try to make the software less configurable so that I can't make it do clever stuff on my computer.