Re: Flexible permissions for REFRESH MATERIALIZED VIEW

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Flexible permissions for REFRESH MATERIALIZED VIEW
Date: 2018-05-15 21:15:12
Message-ID: CA+Tgmob1mJ7isq0uNub+B_c63BNdFBbbSDq3H8Js67wRPhO6EA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 28, 2018 at 9:56 PM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Wed, Mar 28, 2018 at 6:38 PM, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
> wrote:
>> One question I would have is: what proposals exist or have existed for
>> additional privilege bits? How much pressure is there to use some of the
>> remaining bits? I actually looked into the history of the permission bits
>> and found that we can summarize and approximate the history as 10 years of
>> expansion from 4 to 12, then nothing added in the last 10 years.
>
> I made an argument for an "ANALYZE" grant a little while back, and it kinda
> leads one to want one for VACUUM as well.

Yeah, and FWIW, I think that's a totally reasonable request, as is
this one. The problem is that our authentication model seems to have
been designed under the assumption that there weren't all that many
different things you might want to separately GRANT, and the requests
we've had over the years show that this isn't the case. So the
request is reasonable; it's just hard to implement. I think we should
somehow move to a system where there's a set of "core" permissions
that are identified by bits for efficiency, and a set of "extended"
permissions which are identified by names for extensibility. Things
like VACUUM and ANALYZE and REFRESH could be extended permissions.

To handle the on-disk issue, I think we could introduce a new varlena
type that's like aclitem but permits extra variable-length data at the
end. It would be a different data type but pretty easy to convert
back and forth. Still probably a lot of work to make it happen,
though, unfortunately.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2018-05-15 21:28:23 Re: Make description of heap records more talkative for flags
Previous Message Tatsuo Ishii 2018-05-15 21:11:52 Re: Postgres 11 release notes