Re: REVOKE [ADMIN OPTION FOR] ROLE

From: Oleksii Kliukin <alexk(at)hintbits(dot)com>
To: Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVOKE [ADMIN OPTION FOR] ROLE
Date: 2015-07-29 11:06:34
Message-ID: CAAS3tyJ2HaZtCSpoctEOfKK7JQ2DO7DXQwF_GMNwUU3+dnBr-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 28, 2015 at 10:51 AM, Egor Rogov <e(dot)rogov(at)postgrespro(dot)ru> wrote:
>
> Well, I looked into a draft of SQL:2003. It basically says that "cascade"
> for <revoke role statement> must behave the same way as for <revoke
> privilege statement>. That is, from standard's point of view we have a code
> issue.
>
> Still I doubt about usefulness of this behavior. Do we really need it in
> PostgreSQL?

I think it's useful, as long as there are use-cases where instead of
granting privileges on the specific classes of database objects (i.e.
SELECT on all tables in a given schema) a role is granted instead
which 'accumulates' those privileges. This is the case in our
environment, and, while we are not using ADMIN OPTION, I can imagine
it might be used in order to 'delegate' assignment of privileges from
the central authority to responsible sub-authorities in different
departments. Then, if you need to revoke those (i.e. because the
structure of departments had changed), it's enough to REVOKE ..FROM..
CASCADE instead of getting through each individual assignment case.

Kind regards,
--
Oleksii

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-07-29 11:39:49 Re: LWLock deadlock and gdb advice
Previous Message Ashutosh Bapat 2015-07-29 10:58:29 Re: Transactions involving multiple postgres foreign servers