From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Christensen <david(dot)christensen(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE ROLE IF NOT EXISTS |
Date: | 2021-11-04 08:53:10 |
Message-ID: | 475A5F55-21CA-4FEB-A875-394FF841C4A4@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 3 Nov 2021, at 23:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm generally pretty down on IF NOT EXISTS semantics in all cases,
> but it seems particularly dangerous for something as fundamental
> to privilege checks as a role. It's not hard at all to conjure up
> scenarios in which this permits privilege escalation. That is,
> Alice wants to create role Bob and give it some privileges, but
> she's lazy and writes a quick-and-dirty script using CREATE ROLE
> IF NOT EXISTS. Meanwhile Charlie sneaks in and creates Bob first,
> and then grants it to himself. Now Alice's script is giving away
> all sorts of privilege to Charlie. (Admittedly, Charlie must have
> CREATEROLE privilege already, but that doesn't mean he has every
> privilege that Alice has --- especially not as we continue working
> to slice the superuser salami ever more finely.)
I agree with this take, I don't think the convenience outweighs the risk in
this case.
--
Daniel Gustafsson https://vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-11-04 09:03:17 | Re: Logical insert/update/delete WAL records for custom table AMs |
Previous Message | Andreas Seltenreich | 2021-11-04 08:46:49 | [sqlsmith] Failed assertion in brin_minmax_multi_distance_float4 on REL_14_STABLE |