Resource reads return an empty array instead of an error when the API key lacks permission #1594

Komodo 2.3.1, Core API via X-Api-Key / X-Api-Secret.

Behaviour

A service-account API key with Server: Read and Stack: Execute base
permissions, and no permission on any other resource type, gets an empty
array from reads of those other resource types rather than a permission error:

ListServers      -> 4 items      (permitted)
ListStacks       -> 8 items      (permitted)

ListBuilds       -> []
ListRepos        -> []
ListProcedures   -> []
ListAlerters     -> []
ListBuilders     -> []
ListDeployments  -> []

Those six are indistinguishable from a genuinely empty estate. A client cannot
tell "you may not read this" from "there are none".

It is inconsistent with the rest of the API, which does refuse clearly

The same key, same request style:

ListUsers           -> {"error":"this route is only accessable by admins"}
ListOnboardingKeys  -> {"error":"This call is admin only"}
GetStackLog         -> {"error":"User does not have required permissions on this
                        Server. Must have at least Read permissions, as well as
                        these specific permissions: [Logs]"}
InspectDockerContainer
                    -> {"error":"User does not have required permissions on this
                        Server. ..."}

So admin-gated routes and specific sub-permissions produce good errors — the
GetStackLog one even names the exact permission required, which is ideal. It is
specifically the resource-type list reads that return empty instead.

Why it matters

Any automation that reads a collection has to treat every empty result as
potentially a permission fault. In our case a monitoring tool briefly reported
every stack as "never deployed" because a paginated read came back empty, and the
only way to be safe is to assert non-empty everywhere and require an explicit
opt-in wherever nothing is a legitimate answer — which is a workaround for
something the API could state directly.

It also makes least-privilege harder to adopt: narrowing a key silently changes
read results rather than failing loudly, so the narrowing is easy to get wrong
and hard to notice.

Reproduction

1. Create an API key on a non-admin service account
2. Give it Base Permissions Server: Read and Stack: Execute only
3. POST /read with {"type":"ListBuilds","params":{}}
4. Observe [] rather than a permission error

Suggested fix

Return the same style of error these already produce:

{"error":"User does not have required permissions on this resource type: Build"}

An alternative that would also resolve it is documenting the behaviour explicitly,
so clients know an empty collection is ambiguous by design — though an error
matching GetStackLogs would be much easier to build against.

Happy to test a change against this setup if useful.