Re: Have REFRESH MATERIALIZED VIEW run as the MV owner - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Have REFRESH MATERIALIZED VIEW run as the MV owner
Date
Msg-id CAP7Qgmmh3n36bRgFbER0j4AZ4v96=F0rb7TCT1aiP3XnwJk=8g@mail.gmail.com
Whole thread Raw
In response to Have REFRESH MATERIALIZED VIEW run as the MV owner  (Noah Misch <noah@leadboat.com>)
Responses Re: Have REFRESH MATERIALIZED VIEW run as the MV owner
List pgsql-hackers
On Fri, Jul 5, 2013 at 9:45 AM, Noah Misch <noah@leadboat.com> wrote:
> REFRESH MATERIALIZED VIEW should temporarily switch the current user ID to the
> MV owner.  REINDEX and VACUUM do so to let privileged users safely maintain
> objects owned by others, and REFRESH MATERIALIZED VIEW belongs in that class
> of commands.

I was trying to understand why this is safe for a while.  REINDEX and
VACUUM make sense to me because they never contain side-effect as far
as I know, but MV can contain some volatile functions which could have
some unintended operation that shouldn't be invoked by no one but the
owner.  For example, if the function creates a permanent table per
call and doesn't clean it up, but later some other maintenance
operation is supposed to clean it up, and the owner schedules REFRESH
and maintenance once a day.  A non-owner user now can refresh it so
many times until the disk gets full.  Or is that operation supposed to
be restricted by the security context you are adding?

--
Hitoshi Harada



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal
Next
From: Michael Meskes
Date:
Subject: Re: [9.3 bug fix] ECPG does not escape backslashes