> On Mar 6, 2022, at 2:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> 1. If we need to change these two contrib modules, doesn't that imply
> a lot of changes forced on external modules as well? What are the
> security implications if somebody doesn't make such a change?
>
> 2. It looks to me like if someone installs the updated postgres_fdw.so,
> but doesn't run ALTER EXTENSION UPDATE, they are going to be left with a
> rather broken extension. This seems not good either, especially if it's
> multiplied by a boatload of third-party extensions requiring updates.
>
> So I think some more thought is needed to see if we can't avoid
> the need to touch extension modules in this patch. Or at least
> avoid the need for synchronized C-level and SQL-level updates,
> because that is going to create a lot of pain for end users.
>
> I'm also fairly distressed by the number of changes in guc.c,
> mainly because I fear that that means that pending patches that
> add GUC variables will be subtly incorrect/insecure if they're not
> updated to account for this. Frankly, I also reject the apparent
> position that we need to support forbidding users from touching
> many of these GUCs. Or, if that's our position, why are there
> per-GUC changes at all, rather than just redefining what the
> context values mean? (That is, why not redefine USERSET and
> SUSET as simply indicating the default ACL to be applied if there's
> no entry in the catalog.)
To my knowledge, there is no mechanism to revoke an implicit privilege. You
can revoke a privilege explicitly listed in an aclitem[], but only if the
privilege is being tracked that way.
Userset variables are implicitly settable by any user. There was a request,
off-list as I recall, to make it possible to revoke the privilege to set
variables such as "work_mem". To make that possible, but not change the
default behavior vis-a-vis prior releases, I upgraded most userset variables to
suset with a corresponding grant to public on the variable. Sites which wish
to have a more restrictive policy on such variables can revoke that privilege
from public and instead issue more restrictive grants. There were a few
variables where such treatment didn't seem sensible, such as ones to do with
client connections, and I left them alone. I didn't insist on a defense for
why any particular setting needed to be revocable in order to apply this
treatment. My assumption was that sites should be allowed to determine their
own security policies per setting unless there is a technical difficulty for a
given setting that would make it overly burdensome to implement.
It seemed more complete to do the same thing for contrib modules, so I did.
If a third-party module doesn't do the equivalent operation, they would simply
continue with their userset variables working as before. I don't see a
specific security concern with that, though I'd be happy to consider arguments
to the contrary.
I believe there are also some issues with this patch relating to
pg_dump/pg_restore and to pg_upgrade, which EDB is working to address. We
intend to repost something soon.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
