> On May 13, 2021, at 12:18 PM, Jacob Champion wrote:
>
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
>> The distinction that Theme+Security would make is that capabilities
>> can be categorized by the area of the system:
>> -- planner
>> -- replication
>> -- logging
>> ...
>> bu
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> > The distinction that Theme+Security would make is that capabilities
> > can be categorized by the area of the system:
> > -- planner
> > -- replication
> > -- logging
> > .
On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> The distinction that Theme+Security would make is that capabilities
> can be categorized by the area of the system:
> -- planner
> -- replication
> -- logging
> ...
> but also by the security implications of what is being done:
> --
> On May 13, 2021, at 10:41 AM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>>> - Group things by which section of postgresql.conf they're in, and
>>> then further restrict some of them as se
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On May 12, 2021, at 12:58 PM, Robert Haas wrote:
> > - Group things by which section of postgresql.conf they're in, and
> > then further restrict some of them as security-sensitive. This is
> > reasonably close to what you've got,
> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>
> - Group things by which section of postgresql.conf they're in, and
> then further restrict some of them as security-sensitive. This is
> reasonably close to what you've got, but not exactly what you've got.
> One issue is that it risks sep
On Wed, May 12, 2021 at 11:59 AM Mark Dilger
wrote:
> I didn't bother updating the docs yet, as I doubt the set of privileges/roles
> in this patch will survive contact with this list. They are:
>
> [ various things ]
Interesting classification. I think the trick here is going to be to
figure o
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> > I'm still of the opinion that slicing and dicing this at the per-GUC
> > level is a huge waste of effort. Just invent one role that lets
> > grantees set any GUC, document it as being sup
On Mon, May 3, 2021 at 2:48 PM Tom Lane wrote:
> I'm still of the opinion that slicing and dicing this at the per-GUC
> level is a huge waste of effort. Just invent one role that lets
> grantees set any GUC, document it as being superuser-equivalent,
> and be done.
If you want to grant someone f
On Mon, May 3, 2021 at 2:41 PM Stephen Frost wrote:
> In general, I agree that we should be looking at predefined roles as
> being similar to the Linux capabilities system- defining certain kinds
> of operations which the user who has that role is allowed to do, and
> then both in-core and extensi
Stephen Frost writes:
> One thing that seems missing from this discussion and is part of what
> paused my effort on the 'admin' role proposed towards the end of the
> last cycle is that we really need to consider how this all plays with
> ALTER SYSTEM and not just SUSET GUCs but also other (eg: PO
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 3, 2021 at 12:25 PM Mark Dilger
> wrote:
> > As things stand, all custom variables defined via the
> > DefineCustom{Bool,Int,Real,String,Enum}Variable are placed in the
> > CUSTOM_OPTIONS config_group. We could add a role fo
On 05/03/21 13:23, Robert Haas wrote:
> On Mon, May 3, 2021 at 11:45 AM Chapman Flack wrote:
>> I guess I was thinking, but forgot to convey to the keyboard, that the
>> existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
>> could only have been attached from a shared preload li
On Mon, May 3, 2021 at 12:25 PM Mark Dilger
wrote:
> As things stand, all custom variables defined via the
> DefineCustom{Bool,Int,Real,String,Enum}Variable are placed in the
> CUSTOM_OPTIONS config_group. We could add a role for controlling any SUSET
> CUSTOM_OPTIONS GUCs, or we could extend
On Mon, May 3, 2021 at 11:45 AM Chapman Flack wrote:
> I guess I was thinking, but forgot to convey to the keyboard, that the
> existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
> could only have been attached from a shared preload library) would
> implicitly change SUSET to m
> On May 3, 2021, at 8:22 AM, Robert Haas wrote:
>
> One problem with having a separate predefined role for every PGC_SUSET
> GUC is that it's no help for extensions. Both auto_explain and
> pg_stat_statements have such GUCs, and there may be out-of-core
> extensions that do as well. We should
On 05/03/21 11:22, Robert Haas wrote:
>> The GUC system would have to expose a way for the shared object to
>> chain extra_check_hooks off existing GUCs. An extra_check_hook can check
>> both the value and the role of the caller.
>
> I think there are two parts to this problem. First, the SP needs
On Sat, May 1, 2021 at 12:37 PM Chapman Flack wrote:
> Maybe version 0 is where the provider just builds a shared object
> to go in shared_preload_libraries. The provider has probably already
> done a bunch of other stuff more challenging than that.
>
> The GUC system would have to expose a way fo
Hi,
On Fri, Apr 30, 2021 at 04:19:22PM -0700, Mark Dilger wrote:
> PostgreSQL defines a number of GUCs that can only be set by
> superusers. I would like to support granting privileges on subsets of
> these to non-superuser roles, inspired by Stephen Frost's recent work
> on pg_read_all_data and
On 05/01/21 12:13, Mark Dilger wrote:
> Extra syntax for use by the service provider seems much easier to justify.
>
> If the service provider can install extra role-aware check_hooks for gucs,
> and if the include directive for postgresql.conf can specify a role under
> which a postgresql.conf.te
> On May 1, 2021, at 7:07 AM, Chapman Flack wrote:
>
> On 04/30/21 22:00, Mark Dilger wrote:
>> Viewing all of this in terms of which controls allow the tenant to escape
>> a hypothetical sandbox seems like the wrong approach. Shouldn't we let
>> service providers decide which controls would
On 04/30/21 22:00, Mark Dilger wrote:
> Viewing all of this in terms of which controls allow the tenant to escape
> a hypothetical sandbox seems like the wrong approach. Shouldn't we let
> service providers decide which controls would allow the tenant to escape
> the specific sandbox the provider
On Fri, 30 Apr 2021 at 22:00, Mark Dilger
wrote:
> Viewing all of this in terms of which controls allow the tenant to escape
> a hypothetical sandbox seems like the wrong approach. Shouldn't we let
> service providers decide which controls would allow the tenant to escape
> the specific sandbox
> On Apr 30, 2021, at 4:28 PM, Stephen Frost wrote:
>
> “Can’t be used to gain superuser” may be a sufficiently clear grouping, as
> was more or less contemplated by the “admin” approach. If that doesn’t work
> though then we need an understanding of what the limits on these groups are,
>
Stephen Frost writes:
> On Fri, Apr 30, 2021 at 19:19 Mark Dilger
> wrote:
>> PostgreSQL defines a number of GUCs that can only be set by superusers. I
>> would like to support granting privileges on subsets of these to
>> non-superuser roles, inspired by Stephen Frost's recent work on
>> pg_rea
On 04/30/21 19:19, Mark Dilger wrote:
> We could certainly debate which GUCs could be used to escape the sandbox
> vs. which ones could not, but I would prefer a design that allows the
> provider to make that determination.
I find myself wondering how many GUCs flagged SUSET are not flagged that
Greetings,
On Fri, Apr 30, 2021 at 19:19 Mark Dilger
wrote:
> PostgreSQL defines a number of GUCs that can only be set by superusers. I
> would like to support granting privileges on subsets of these to
> non-superuser roles, inspired by Stephen Frost's recent work on
> pg_read_all_data and pg_
27 matches
Mail list logo
