Re: Cascade view drop permission checks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "m7onov(at)gmail(dot)com" <m7onov(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Cascade view drop permission checks
Date: 2022-04-06 13:48:41
Message-ID: 3035285.1649252921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tuesday, April 5, 2022, m7onov(at)gmail(dot)com <m7onov(at)gmail(dot)com> wrote:
>> It seems strange to me that somebody who is not a member of owner role can
>> drop an object bypassing permission checks.
>> Is this behaviour OK?

> The system dropped the now defunct view, not alice. Bob accepted that risk
> by basing the view on an object owned by another role. I suppose other
> behaviors are possible but not really worth exploring.

(a) this behavior is what is required by the SQL standard.

(b) what other behavior would be better? Dropping the table and
leaving a broken view behind isn't good. Neither is refusing to
let the owner drop her object.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2022-04-06 14:20:31 Re: Cascade view drop permission checks
Previous Message David G. Johnston 2022-04-06 12:16:01 Re: Cascade view drop permission checks