From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Durumdara <durumdara(at)gmail(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Role for just read the data + avoid CREATE / ALTER / DROP |
Date: | 2023-08-25 14:20:48 |
Message-ID: | CAKFQuwYa-rS2vUq8kvbB+UjJEvttv1LYqzhmV4jJyYbxCRZT2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Friday, August 25, 2023, Durumdara <durumdara(at)gmail(dot)com> wrote:
>
> I don't understand why these commands don't work?!
>
> *REVOKE CREATE ON SCHEMA public FROM u_tdb_ro;*
>
> *REVOKE CREATE ON DATABASE tdb FROM u_tdb_ro;REVOKE CREATE ON TABLESPACE
> pg_default FROM u_tdb_ro;*
>
>
Because at no point has the system ever actually granted those specific
permissions to that specific role. When you revoke something it has to
have been previously granted. The underlying complication is permission
inheritance. You need to know where in the inheritance chain a permission
originates in order to know your options for removing it. In this case the
grant to the public group that all roles are a member of.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferrari | 2023-08-25 14:52:30 | Re: ora2pg -c ora2pg.conf -t COPY -a tablename not working properly |
Previous Message | Thomas Kellerer | 2023-08-25 14:02:40 | Re: Role for just read the data + avoid CREATE / ALTER / DROP |