Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Marc Munro <marc@bloodnok.com> writes:
> > On Mon, 2020-02-17 at 22:48 -0500, Tom Lane wrote:
> >> An RLS policy is a table "subsidiary object" so it only depends indirectly
> >> on the extension that owns the table.
>
> > Yep, I get that, and I see the dependency chain in the catalog.
>
> > However an extension can create the table with or without the policy,
> > and a table created by an extension without policy can later have a
> > policy added, and, unless I'm missing something, the same dependency
> > chain exists in either case.
>
> > This means that I cannot tell whether the policy was added by the
> > extension or not.
>
> I can't get very excited about that, since the same argument could be
> made about triggers, indexes, or rules attached to a table, but no
> one has yet complained about those cases. It's fairly hard to see the
> use-case where it matters, anyway. If you're attaching policies to
> tables owned by an extension after-the-fact, you're modifying the
> definition of an extension-owned object, which is at best really poor
> practice. We say up-front that you cannot expect the extension
> mechanism to track the effects of such changes.
This isn't actually entirely correct because there are clear and
specific cases which we support where an extension object is modified,
in a manner of speaking, after the extension has been installed- and
that's through the GRANT system. The entire point of pg_init_privs is
to provide a way to distinguish between what the installed extension's
original privileges were and what were added later, so that pg_dump can
correctly dump out the delta between the two.
Policies, also being part of the overall privilege system, could
certainly be looked at in a similar light as being different from
triggers and indexes. In particular, anything to do with the privilege
system is going to have some dependency on roles and it's rather rare
for an extension to define roles- instead you'd expect the extension to
be installed in a 'safe' manner, with the user able to GRANT rights or
enable RLS and set up policies on objects from the extension after
installation to allow certain users to have access to the extension's
objects.
While it's not as nice a solution at the pg_init_privs system, I would
be inclined to state explicitly (and perhaps even enforce) that enabling
RLS or creating policies as part of an extension isn't supported, and
then modify pg_dump to always dump out those attributes of extension
objects if they exist. When it comes to the GRANT system, we *must*
have a way for extensions to revoke access to certain types of objects
because they start out not-safe (specifically, functions), but as long
as we have that we can always tell extension authors and users that they
can arrange to have no one have access to the extension's tables by
default and they can then enable RLS and add policies after the
extension is installed.
Thanks,
Stephen