fix(frontend): harden SHOW object visibility

[tabVersion]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

Replacement PR for #25571 and #25584. The previous PR #25571 had a stale GitHub synthetic ref refs/pull/25571/head, so Buildkite could only fetch the old head ref and could not checkout the branch/PR API head. The first replacement #25584 was created while #25571 was still in that bad state and GitHub did not create refs/pull/25584/head. This PR uses the same final code/tree on a fresh branch after closing #25571, so Buildkite should be able to fetch the correct PR head ref.

What's changed and what's your intention?

This PR hardens user-visible SHOW metadata surfaces so a user with schema visibility alone cannot enumerate object names or secret references that they do not have object-level privilege for.

Changes:

• Switch clear SHOW object-list handlers to ACL-aware schema iterators:
  • SHOW TABLES
  • SHOW INTERNAL TABLES
  • SHOW VIEWS
  • SHOW MATERIALIZED VIEWS
  • SHOW SOURCES
  • SHOW SINKS
  • SHOW SUBSCRIPTIONS
  • SHOW SECRETS
  • SHOW CONNECTIONS
  • SHOW FUNCTIONS
• Make SHOW COLUMNS FROM <table/source> and SHOW INDEXES FROM <table> use the normal batch binder path instead of the system binder path, avoiding known-name metadata probing for hidden relations.
• Add explicit object-visibility checks for SHOW COLUMNS FROM <sink/view> while preserving system-view column introspection.
• Redact referenced secret names from visible connection output when the current user can see the connection but cannot see the referenced secret. In that case the output renders SECRET <redacted> instead of SECRET schema.secret_name.
• Apply the same connection secret-ref redaction to rw_catalog.rw_connections.
• Add targeted SQLLogicTest coverage for hidden object-list results, known-name probing, connection secret-ref redaction, and source/sink/connection SHOW visibility in their corresponding docker-backed e2e suites.

Current limitation / follow-up:

• During audit, rw_catalog.rw_sources was identified as a separate system-catalog surface that can still need visibility/secret-reference hardening. Iceberg-related catalog views should also be triaged in a follow-up pass.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

RisingWave now avoids exposing unauthorized object names through SHOW object-list commands and known-name SHOW COLUMNS / SHOW INDEXES probes. Visible connection metadata also redacts referenced secret names when the user cannot independently see the secret.

Local verification

Passed:

• git diff --check -- e2e_test/ddl/show_object_privilege.slt e2e_test/source_inline/connection/schema_registry.slt e2e_test/source_inline/kafka/secret_dep.slt e2e_test/sink/blackhole_sink.slt
• cargo fmt --all -- --check
• cargo check -p risingwave_frontend

Attempted but blocked locally:

• ./risedev psql -c "select 1" failed because no RisingWave server was running on 127.0.0.1:4566, so local SLT was not run.

[tabVersion]

Current CI blocker is checkout/ref generation, not a product/test failure. Evidence at the time of this comment:

• PR API head: e4159b07446576310810dd6369e9a4d557a13801
• Branch ref: refs/heads/ralph/show-object-visibility-hardening-v3 -> e4159b07446576310810dd6369e9a4d557a13801
• GitHub has generated refs/pull/25585/merge, but refs/pull/25585/head is absent.
• Buildkite fetches refs/pull/25585/head, so pipeline upload fails before any tests run:
  fatal: couldn't find remote ref refs/pull/25585/head
• A manual attempt to push the hidden ref was rejected by GitHub with deny updating a hidden ref.

The code branch itself is present and the PR API head is correct; this likely needs GitHub/ref-generation or Buildkite checkout-source intervention rather than another code change.

[tabVersion]

Additional ref-generation probes:

• fix(frontend): harden SHOW object visibility #25586 used a different same-repository branch namespace (codex/show-vis-hardening-ci-ref-reset) with a fresh commit, but GitHub still generated only refs/pull/25586/merge and no refs/pull/25586/head.
• fix(frontend): harden SHOW object visibility #25587 used a fork branch from tabVersion/risingwave with a fresh commit, but GitHub still generated only refs/pull/25587/merge and no refs/pull/25587/head.
• A longer wait did not change the ref state.

So this is no longer isolated to the original ralph/show-object-visibility-hardening branch or same-repo PR setup. Keeping this PR as the active tracking PR for the SHOW visibility fix; the blocker remains GitHub PR head-ref generation / Buildkite checkout dependency on refs/pull/<PR>/head.

[xiangjinwu]

@tabVersion Could you STOP SPAMMING? Add reviewers when you are ready

[tabVersion]

@tabVersion Could you STOP SPAMMING? Add reviewers when you are ready

The pr is ready for review, just had some trouble debuging buildkite

$ git fetch -v --prune -- origin refs/pull/25585/head
--
POST git-upload-pack (401 bytes)
fatal: couldn't find remote ref refs/pull/25585/head
⚠️ Warning: Checkout failed! fetching PR refspec "refs/pull/25585/head": exit status 128 (Attempt 3/3)
🚨 Error: fetching PR refspec "refs/pull/25585/head": exit status 128

[tabVersion]

Thanks for the SHOW visibility hardening work. I checked the current CI for buildkite/pull-request build 95735 and the red jobs are not showing a product regression yet; they fail before the intended SHOW assertions run because the new system ok commands invoke raw psql without the RisingWave frontend host/port. I left one inline note with the concrete blocker. The frontend code changes otherwise look aligned with the intended ACL filtering/redaction approach from my pass.