Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
Cc: Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?
Date: 2022-09-15 04:38:58
Message-ID: 3120830.1663216738@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bryn Llewellyn <bryn(at)yugabyte(dot)com> writes:
> I just confirmed that, if it suits me, I can revoke "execute" from "public" on all overloads of the humble length() function. Maybe I should refer to it as "pg_catalog.length()" to emphasize another point that had escaped me.

Yup. For even more fun, try revoking privileges on a function that
underlies an operator.

regression=# revoke execute on function int4pl from public;
REVOKE
regression=# select 2+2; -- still works, for a superuser
?column?
----------
4
(1 row)

regression=# create user joe;
CREATE ROLE
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> select 2+2; -- not so much for anybody else
ERROR: permission denied for function int4pl

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Matthias Apitz 2022-09-15 05:33:49 Re: Mysterious performance degradation in exceptional cases
Previous Message misha1966 misha1966 2022-09-15 04:24:21 Re[2]: CVE-2022-2625