Re: [PATCH] DefaultACLs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] DefaultACLs
Date
Msg-id 603c8f070910011820w5ed09055n399811239af4ba0c@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] DefaultACLs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] DefaultACLs  (Petr Jelinek <pjmodos@pjmodos.net>)
List pgsql-hackers
On Thu, Oct 1, 2009 at 1:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Petr Jelinek <pjmodos@pjmodos.net> writes:
>> because it seems like merging privileges seems to be acceptable for most
>> (although I am not sure I like it, but I don't have better solution for
>> managing conflicts), I changed the patch to do just that.
>
> It's not clear to me whether we have consensus on this approach.
> Last chance for objections, anyone?
>
> The main argument I can see against doing it this way is that it doesn't
> provide a means for overriding the hard-wired public grants for object
> types that have such (principally functions).  I think that a reasonable
> way to address that issue would be for a follow-on patch that allows
> changing the hard-wired default privileges for object types.  It might
> well be that no one cares enough for it to matter, though.  I think that
> in most simple cases what's needed is a way to add privileges, not
> subtract them --- and we're already agreed that this mechanism is only
> meant to simplify simple cases.

I'm going to reiterate what I suggested upthread...  let's let the
default, global default ACL contain the hard-wired privileges, instead
of making them hardwired.  Then your objects will get those privileges
not because they are hard-wired, but because you haven't changed your
global default ACL to not contain them.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Limit allocated memory per session
Next
From: KaiGai Kohei
Date:
Subject: Re: CREATE OR REPLACE FUNCTION vs ownership