Re: Improve docs wrt catalog object ACLs

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

In response to

Browse pgsql-hackers by date

  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?