RLS on custom schemas created by Timescale

[nCrafts]

Bug report

Describe the bug

I don't know if the issue is with security reporting or how extensions work, but enabling timescale in Supabase throws up a lot of errors in the security advisor. Timescale creates a bunch of schemas like _timescaledb_cache when enabled, and these schemas are accessible by the PUBLIC role.

Here is an example of a create script run by Timescale:

ALTER TABLE IF EXISTS _timescaledb_cache.cache_inval_hypertable
    OWNER to supabase_admin;

REVOKE ALL ON TABLE _timescaledb_cache.cache_inval_hypertable FROM PUBLIC;

GRANT SELECT ON TABLE _timescaledb_cache.cache_inval_hypertable TO PUBLIC;

GRANT ALL ON TABLE _timescaledb_cache.cache_inval_hypertable TO supabase_admin;

Supabase says:

RLS Disabled in Public
Security
Entity
_timescaledb_cache.cache_inval_hypertable
Issue
Table _timescaledb_cache.cache_inval_hypertable is public, but RLS has not been enabled.

Description
Detects cases where row level security (RLS) has not been enabled on a table in the public schema.

The new schemas are not in the 'search' path, or a part of the 'public' schema. Are they still somehow available and vulnerable?

To Reproduce

Simply enable the timescaledb extension:

CREATE EXTENSION timescaledb WITH SCHEMA addons;

Expected behavior

If this is an issue with the extension: the schemas should not have PUBLIC access.

If this is an issue with the security advisor: it shouldn't report this as being an issue.

[olirice]

Thanks for reporting. We resolved this with https://github.com/supabase/splinter/pull/70 2 days ago but it hasn't propagated to Studio yet. If you give another day or two you should see clear

[ziegfried]

Still seeing this, has the fix landed in studio yet?

[olirice]

Not quite yet. You can track the production rollout here https://github.com/supabase/supabase/pull/26263