Re: [PATCH] DefaultACLs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Petr Jelinek <pjmodos(at)pjmodos(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, "Jan Urban'ski" <wulczer(at)wulczer(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] DefaultACLs
Date: 2009-09-29 15:33:35
Message-ID: 603c8f070909290833p1f8e41c2k3fa20b70e9624cb5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 29, 2009 at 11:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Petr Jelinek <pjmodos(at)pjmodos(dot)net> writes:
>> That's how it works now actually, the problem is that when you grant
>> something in the chain you can't revoke it anywhere else in the chain
>> when you are merging privileges as you proposed.
>
> To allow that, you have to have some notion of a priority order among
> the available defaults, so that you can sensibly say that A should
> override B.  Which is easy as long as they've got hierarchical scopes,
> but that doesn't seem like a restriction that will hold good for future
> extensions.

Yeah. Right now AIUI we have these:

grant default privileges across the board
grant default privileges to objects in schema X

In the future maybe we might have:

grant default privileges to all objects EXCEPT those in schemas A, B, C.

I'm not real sure whether this sensible and I'm not real sure whether
it's too baroque to be worthwhile, but I am fairly confident that it
doesn't create any nasty semantic problems, which can't be said for
any approach that involves permissions for schemas "overrriding" the
global permissions, which will break down horribly as soon as we want
to do anything orthogonal.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-09-29 15:35:15 Re: navigation menu for documents
Previous Message Alvaro Herrera 2009-09-29 15:29:57 Re: Using results from INSERT ... RETURNING