Improve docs wrt catalog object ACLs
Greetings,
The way permissions on catalog objects are handled isn't discussed at
all in the documentation. Barring objections, I'll commit and
back-patch the attached to improve that situation in the next day or so.
Thanks!
Stephen
Attachments:
catalog-acl-docfix.patchtext/x-diff; charset=us-asciiDownload
From ad8e663893ea906238a9c0346bf8791eafe3d333 Mon Sep 17 00:00:00 2001
From: Stephen Frost <sfrost@snowman.net>
Date: Wed, 10 Feb 2016 13:28:11 -0500
Subject: [PATCH] Add note regarding permissions in pg_catalog
Add a note to the system catalog section pointing out that while
modifying the permissions on catalog tables is possible, it's
unlikely to have the desired effect.
---
doc/src/sgml/catalogs.sgml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 412c845..3e8ebee 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -21,6 +21,17 @@
particularly esoteric operations, such as adding index access methods.
</para>
+ <note>
+ <para>
+ Changing the permissions on objects in the system catalogs, while
+ possible, is unlikely to have the desired effect as the internal
+ lookup functions use a cache and do not check the permissions nor
+ policies of tables in the system catalog. Further, permission
+ changes to objects in the system catalogs are not preserved by
+ pg_dump or across upgrades.
+ </para>
+ </note>
+
<sect1 id="catalogs-overview">
<title>Overview</title>
--
2.5.0
Stephen Frost <sfrost@snowman.net> writes:
The way permissions on catalog objects are handled isn't discussed at
all in the documentation. Barring objections, I'll commit and
back-patch the attached to improve that situation in the next day or so.
I have no objection to the goal, but I do not think this wording is very
helpful. In particular I find the terminology "catalog object" vague
and confusing: are you talking about catalogs, objects described in the
catalogs, or both?
You probably need to distinguish at least two cases:
1. Altering permissions on system catalogs, as such, only restricts what
can be done by user queries on the catalogs; the database's internal
operations do not check permissions when accessing or updating catalogs.
Thus for example denying select on pg_proc does not stop the parser from
looking up function names, but it would break psql's \df.
2. Altering permissions on built-in objects, such as built-in functions,
does work to the extent that those objects are used in user queries (and
not by internal operations).
The point about such changes not being preserved across pg_dump or
pg_upgrade applies to both cases.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers