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

From Robert Haas
Subject Re: public schema default ACL
Date
Msg-id CA+Tgmob9=HeiLaKzYhxqkjQEOJgcvmfVAFsL9+7RVhhJ1fshEA@mail.gmail.com
Whole thread Raw
In response to Re: public schema default ACL  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Mon, Nov 2, 2020 at 1:41 PM Stephen Frost <sfrost@snowman.net> wrote:
> > What potentially could move the needle is separate search paths for
> > relation lookup and function/operator lookup.  We have sort of stuck
> > our toe in that pond already by discriminating against pg_temp for
> > function/operator lookup, but we could make that more formalized and
> > controllable if there were distinct settings.  I'm not sure offhand
> > how much of a compatibility problem that produces.
>
> While I agree with the general idea of giving users more granularity
> when it comes to what objects are allowed to be created by users, and
> where, and how objects are looked up, I really don't think this would
> end up being a sufficiently complete answer to a world-writable public
> schema.  You don't have to be able to create functions or operators in
> the public schema to make things dangerous for some other user poking
> around at the tables or views that you are allowed to create there.

I agree. Everything that can execute code is a risk, which also
includes things like triggers and RLS policies. Noah's certainly right
about the compatibility hazard, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Matthieu Garrigues
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq