sql: add VIEWSCHEDULE and VIEWEVENTLOG system privileges

[souravcrl]

Summary

• Adds VIEWSCHEDULE (Kind 45) and VIEWEVENTLOG (Kind 46) system
  privileges, following the pattern of VIEWJOB, VIEWACTIVITY, etc.
• VIEWSCHEDULE explicitly gates SHOW SCHEDULES and grants implicit
  SELECT on system.scheduled_jobs and system.jobs.
• VIEWEVENTLOG grants read-only access to system.eventlog and the
  DB Console Events page. The gRPC Events API now accepts either
  VIEWEVENTLOG or the existing VIEWCLUSTERMETADATA.
• Fixes the DB Console schedules API to check for SQL execution errors
  before accessing results, preventing runtime crashes on privilege errors.

Previously, SHOW SCHEDULES was implicitly gated by SELECT on
system.scheduled_jobs (admin-only), and viewing the event log required
admin or VIEWCLUSTERMETADATA — both overprivileged for users who
only need schedule or event visibility. Non-admin users can now be
granted scoped access:

GRANT SYSTEM VIEWSCHEDULE TO <user>;
GRANT SYSTEM VIEWEVENTLOG TO <user>;

Fixes: #169420
Fixes: #169421
Epic: none

Release note (sql change): Added two new system privileges:
VIEWSCHEDULE controls access to SHOW SCHEDULES, and VIEWEVENTLOG
grants read-only access to the event log. Non-admin users can be granted
scoped visibility via GRANT SYSTEM VIEWSCHEDULE TO <user> and
GRANT SYSTEM VIEWEVENTLOG TO <user> without needing broad system
table access or the admin role.

DB Console Demo

Individual Screenshots

Schedules — without VIEWSCHEDULE (error)

Events — without VIEWEVENTLOG (error)

Schedules — with VIEWSCHEDULE (working)

Events — with VIEWEVENTLOG (working)

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[cockroach-teamcity]

This change is 

[blathers-crl]

Detected infrastructure failure (matched: self-hosted runner lost communication with the server). Automatically rerunning failed jobs. (run link)

[github-actions]

Bug: This upfront guard exclusively requires VIEWSCHEDULE on GlobalPrivilegeObject (a synthetic privilege object), so the VIEWSYSTEMTABLE fallback in authorization.go:264-273 — which only applies to system table descriptors — is never reached. Any non-admin user who currently accesses SHOW SCHEDULES via VIEWSYSTEMTABLE or direct SELECT grants on system.scheduled_jobs/system.jobs will get "does not have VIEWSCHEDULE system privilege" after this change, even though they have sufficient access to the underlying data.

The simplest fix is to remove this upfront guard entirely: the delegated query (SELECT ... FROM system.scheduled_jobs) will naturally hit the table-level privilege checks in authorization.go, which already correctly handle VIEWSYSTEMTABLE, VIEWSCHEDULE, and direct SELECT grants. Alternatively, expand this check to also accept VIEWSYSTEMTABLE.

Note that the analogous SHOW JOBS command has no such upfront gate, confirming this is inconsistent.

[rafiss]

I agree with this comment. do we actually need the check here if there already is one in authorization.go?

We should be able to confirm this via a logictest.

[souravcrl]

Good catch on the VIEWSYSTEMTABLE regression. I tested removing the upfront guard entirely and the behavior is:

• Without the guard, the error is "user testuser does not have SELECT privilege on relation scheduled_jobs" — which doesn't tell the user what privilege they need.
• With the guard, we get a clear "does not have VIEWSCHEDULE system privilege".

So the guard serves a UX purpose (clear error message), but as written it blocks VIEWSYSTEMTABLE users which is a regression. I've updated the guard to also check VIEWSYSTEMTABLE — if the user has neither VIEWSCHEDULE nor VIEWSYSTEMTABLE, they get the clear error. If they have VIEWSYSTEMTABLE, the guard passes and the query executes with the implicit SELECT from authorization.go.

I've also added a logictest case confirming that VIEWSYSTEMTABLE still works for SHOW SCHEDULES.

[github-actions]

AI Review: Potential Issue(s) Detected

An inline comment has been added to pkg/sql/delegate/show_schedules.go (lines 28-33) identifying a privilege regression.

Summary: The upfront VIEWSCHEDULE guard blocks users who previously accessed SHOW SCHEDULES via VIEWSYSTEMTABLE or direct SELECT grants on the underlying system tables. Since the check targets GlobalPrivilegeObject (a synthetic object), the VIEWSYSTEMTABLE fallback in authorization.go is never reached. This silently revokes access for non-admin users relying on existing privilege paths.

View full analysis

---

If helpful: add O-AI-Review-Real-Issue-Found label.
If not helpful: add O-AI-Review-Not-Helpful label.

[souravcrl]

DB Console Manual Test Results

Tested the Schedules and Events pages with a non-admin user (testnopriv).

Test Flow (recorded via Playwright):

Step	Page	Privilege	Result
1	Schedules (/#/schedules)	None	Error: "user testnopriv does not have VIEWSCHEDULE system privilege"
2	Events (/#/events)	None	Error: "user testnopriv does not have SELECT privilege on relation eventlog"
3	Schedules	GRANT SYSTEM VIEWSCHEDULE	Shows 2 schedules (sql-schema-telemetry, sql-stats-compaction)
4	Events	GRANT SYSTEM VIEWEVENTLOG	Shows event log entries
5	Schedules	REVOKE SYSTEM VIEWSCHEDULE	Error returns
6	Events	REVOKE SYSTEM VIEWEVENTLOG	Error returns

All pages display inline error alerts when privilege is missing, and render data correctly when privilege is granted.

[rafiss]

Nice work! I reviewed the privilege-related changes, and it looks good, with just a minor nit.

For changes in the frontend and RPC endpoints, please ask the o11y team.

This also seems to resolve #103341 -- i will add that issue linkage to this PR.

@rafiss made 3 comments.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on kyle-a-wong and souravcrl).

---

pkg/server/admin.go line 1494 at r2 (raw file):

			// Fall back to the existing VIEWCLUSTERMETADATA check.
			if err := s.privilegeChecker.RequireViewClusterMetadataPermission(ctx); err != nil {
				return nil, err

When a non-admin lacks both privileges, the user only sees "requires the VIEWCLUSTERMETADATA system privilege" — they're never told VIEWEVENTLOG would also work.

consider using errors.WithMessage so we can mention that information. another alternative would be to modify the privilegeChecker interface so both privileges can be checked with the same call.

[rafiss]

I agree with this comment. do we actually need the check here if there already is one in authorization.go?

We should be able to confirm this via a logictest.

[souravcrl]

@souravcrl made 1 comment.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on kyle-a-wong and rafiss).

---

pkg/server/admin.go line 1494 at r2 (raw file):

Previously, rafiss (Rafi Shamim) wrote…

When a non-admin lacks both privileges, the user only sees "requires the VIEWCLUSTERMETADATA system privilege" — they're never told VIEWEVENTLOG would also work.

consider using errors.WithMessage so we can mention that information. another alternative would be to modify the privilegeChecker interface so both privileges can be checked with the same call.

done