| 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: | Whole Thread | Raw Message | 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 |