From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Improve docs wrt catalog object ACLs |
Date: | 2016-02-10 18:50:57 |
Message-ID: | 31585.1455130257@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-02-10 18:54:38 | Re: proposal: schema PL session variables |
Previous Message | Robert Haas | 2016-02-10 18:50:40 | Re: Way to check whether a particular block is on the shared_buffer? |