Re: public schema default ACL

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: public schema default ACL
Дата
Msg-id 20201102153910.GR16415@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: public schema default ACL  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Greetings,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 2020-10-31 17:35, Noah Misch wrote:
> >Overall, that's 3.2 votes for (b)(3)(X) and 0.0 to 1.0 votes for changing
> >nothing.  That suffices to proceed with (b)(3)(X).  However, given the few
> >votes and the conspicuous non-responses, work in this area has a high risk of
> >failure.  Hence, I will place it at a low-priority position in my queue.
>
> My vote would also be (b)(3)(X).  Allowing the database owner to manage the
> public schema within their database makes a lot of sense, independent of any
> overarching goals.

Agreed.

> I'm not convinced, however, that this would would really move the needle in
> terms of the general security-uneasiness about the public schema and search
> paths.  AFAICT, in any of your proposals, the default would still be to have
> the public schema world-writable and in the path.

Looks like the proposal wasn't explicitly clear on this point and I, at
least, took the proposal to implicitly also be saying that the public
schema's ACL would be the default- meaning that the owner would be able
to create objects in the schema and to use it, but other users wouldn't
be able to (or, perhaps, that USAGE rights would be GRANT'd to public,
but not CREATE).

Seems we probably need another round of votes where it's made very clear
what the default ACL (not from a dump/reload) on the public schema would
be.

Thanks,

Stephen

Вложения

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

Предыдущее
От: Isaac Morland
Дата:
Сообщение: Re: Getting rid of aggregate_dummy()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: PATCH: Batch/pipelining support for libpq