Re: public schema default ACL - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: public schema default ACL
Date
Msg-id 20201102153910.GR16415@tamriel.snowman.net
Whole thread Raw
In response to Re: public schema default ACL  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Isaac Morland
Date:
Subject: Re: Getting rid of aggregate_dummy()
Next
From: Alvaro Herrera
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq