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
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 |