From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: public schema grants to PUBLIC role |
Date: | 2023-03-09 13:13:30 |
Message-ID: | 24e22a98cf1fb142eedfc0da2861ec0cceee7f29.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2023-03-09 at 10:34 +0100, Dominique Devienne wrote:
> Hi. I've recently realized via a post (or article?) from Laurenz that the PUBLIC
> role has CREATE privilege on the 'public' schema by default (see query below).
> I guess it can't be avoided?
It can be avoided if you connect to "template1" and
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
there *before* you create a new database.
Or, as Christoph said, if you use v15 or better.
> OK, then I'll REVOKE that privilege when creating a new DB.
> Like I already revoked the default CONNECT to PUBLIC on the DB.
Excellent.
> But I'm wondering about unexpected side-effets.
> In particular, we need extensions, which are loaded in public by default.
> Will USAGE of public be enough for LOGIN users having access to the DB to use extensions?
Yes, that is enough.
> More broadly, we want to secure the DB so that all DB access and schema access are explicit.
> Anything else to be aware of please, beside the two mentioned above?
Avoid SECURITY DEFINER functions with no "search_path" set:
https://www.cybertec-postgresql.com/en/abusing-security-definer-functions/
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-03-09 13:22:02 | Re: crosstab |
Previous Message | Tim Clarke | 2023-03-09 12:14:30 | RE: Blog post series on commitfests and patches |