What else are you expected to do with a product that you don't fully understand (since you're just evaluating it here), and the thing doesn't work and doesn't provide any sort of useful diagnostics?

Oh great, it's saying permission denied, but doesn't tell me where the permission was denied. Now I have to check all permissions everywhere to figure out what the problem is, once I figure out how the product works and where it might have permissions.

I do sysadmin work almost exclusively. The scenario you're describing is, basically, the norm in my life.

I'd take at look at OS and application service logs, then break out the various flavors of diagnostic tools-- strace, ProcMon, etc. It's not ideal, but it's the sorry state of affairs in the industry.

Insecure-by-default isn't the answer to bad error messages.

That argument is fine for initial investigation into a product, when you just want it to work so you can poke the features to see if they are adequate and suitable.

But the problem is people doing it that way and putting the result into production without any sort of security review.

You troubleshoot, investigate, and research -- what systems guys have done since the beginning of computing.

If you're a developer (not you, per se) running into these types of issues, well, now you understand why -- until recently -- there has traditionally been a separate operations group that was responsible for this type of stuff.