From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Olegs Jeremejevs <olegs(at)jeremejevs(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Rationale for PUBLIC having CREATE and USAGE privileges on the schema "public" by default |
Date: | 2018-02-17 21:49:08 |
Message-ID: | CAKFQuwY20P+41JDiOFRTOaFYihncBAKus5zNh36W3X1zRirgWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Saturday, February 17, 2018, Olegs Jeremejevs <olegs(at)jeremejevs(dot)com>
wrote:
> Okay, in other words, there's no way to completely defend oneself from DoS
> attacks which require having a session? If so, is there a scenario where
> some bad actor can create a new user for themselves (to connect to the
> database with), and not be able to do anything more damaging than that? For
> example, if I can do an SQL injection, then I can do something more clever
> than running a CREATE ROLE. And if not, then there's no point in worrying
> about privileges in a single-tenant database? Beyond human error safeguards.
>
Roles that applications use should not be superuser or given createrole so
your example should not arise. But any logged user can do something like:
Select * from generate_series1,100000000) cross join
generate_series(1,100000000)
Privileges are largely valuable for information privacy and security, and
preventing subtle attacks.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Shepard | 2018-02-17 22:00:43 | Need to fix one more glitch in upgrade to -10.2 |
Previous Message | Tim Clarke | 2018-02-17 21:37:48 | Re: Rationale for PUBLIC having CREATE and USAGE privileges on the schema "public" by default |