public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Mark Dilger <[email protected]>
Cc: Joshua Brindle <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: Joe Conway <[email protected]>
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
Date: Sun, 06 Mar 2022 18:27:43 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CA+TgmobaKUYZhfXs-7kHjsmDmkcttH7-r9E2BJXUHtv9mkUUcw@mail.gmail.com>
<[email protected]>
<CA+TgmobUt_tSF-9tz-eRvWzT1pbe_ssvxfnPniGGEgLzems40Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAGB+Vh4_UJsYHCWborm-y4CFt8gVvY_KbcNrpWcpXAk-GcwOtA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Mark Dilger <[email protected]> writes:
> On Mar 6, 2022, at 2:57 PM, Tom Lane <[email protected]> wrote:
>> I don't think this is materially different from what we do with
>> permissions on (say) functions. If you want to revoke the public
>> SET privilege on some USERSET variable, you instantiate the default
>> and then revoke. You end up with an empty ACL stored in pg_setting_acl,
>> and voila.
> I assume you mean the implementation of REVOKE does this, not that the user needs to do both a grant and a revoke.
Right. Again, look at what happens when you create a function and
then revoke its default PUBLIC EXECUTE permission.
>> It'd likely be necessary to refuse to record a grant/revoke on
>> an unknown GUC, since if we don't know the GUC then we can't know
>> what the relevant default ACL ought to be. But I bet your existing
>> patch has some dubious behavior in that case too.
> The existing patch allows grants on unknown gucs, because it can't know what guc an upgrade script will introduce, and the grant statement may need to execute before the guc exists.
Yeah, that's the problematic case. It might mostly work to assume that
an unknown GUC has an empty default ACL. This could fail to retain the
default PUBLIC SET permission if it later turns out the GUC is USERSET
... but I suspect in most cases anybody who's messing with the permissions
would've started out by revoking that anyway. We could make this
definitely work in pg_dump if we teach pg_dump to explicitly grant or
revoke the PUBLIC SET permission anytime it's emitting anything for
a GUC, even if it thinks that would be the default state anyway.
Extension scripts that want to modify permissions for their GUCs
could follow that same principle to be sure.
regards, tom lane
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Granting SET and ALTER SYSTE privileges for GUCs
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox