We don't need to restrict column privileges on pg_statistic_ext;
all of that data is OK to read publicly. What we *do* need to do,
which was overlooked by
6cbfb784c, is revoke public read access on
pg_statistic_ext_data; otherwise we still have the same security
hole we started with.
Catversion bump to ensure that installations calling themselves
beta2 will have this fix.
Diagnosis/correction by Dean Rasheed and Tomas Vondra, but I'm
going to go ahead and push this fix ASAP so we get more buildfarm
cycles on it.
Discussion: https://postgr.es/m/8833.
1560647898@sss.pgh.pa.us
WHERE NOT has_column_privilege(c.oid, a.attnum, 'select') )
AND (c.relrowsecurity = false OR NOT row_security_active(c.oid));
-REVOKE ALL on pg_statistic_ext FROM public;
-GRANT SELECT (tableoid, oid, stxrelid, stxname, stxnamespace, stxowner, stxkeys, stxkind)
- ON pg_statistic_ext TO public;
+-- unprivileged users may read pg_statistic_ext but not pg_statistic_ext_data
+REVOKE ALL on pg_statistic_ext_data FROM public;
CREATE VIEW pg_publication_tables AS
SELECT
*/
/* yyyymmddN */
-#define CATALOG_VERSION_NO 201906152
+#define CATALOG_VERSION_NO 201906161
#endif