Re: Rationale for PUBLIC having CREATE and USAGE privileges on the schema "public" by default

Okay, thanks, I'll stop worrying about the defaults then. Have a nice
evening!

Olegs

On Sat, Feb 17, 2018 at 11:49 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

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