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

Поиск
Список
Период
Сортировка
От Olegs Jeremejevs
Тема Re: Rationale for PUBLIC having CREATE and USAGE privileges on theschema "public" by default
Дата
Msg-id CAOpVyVvoVyLCSc-SG-q_C1Cwj_VVWL2bmbGF-rOB_HoW44vqnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Rationale for PUBLIC having CREATE and USAGE privileges on theschema "public" by default  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
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.g.johnston@gmail.com> wrote:
On Saturday, February 17, 2018, Olegs Jeremejevs <olegs@jeremejevs.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.


В списке pgsql-general по дате отправления:

Предыдущее
От: Rich Shepard
Дата:
Сообщение: Need to fix one more glitch in upgrade to -10.2
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Need to fix one more glitch in upgrade to -10.2