Re: public schema default ACL
От | Robert Haas |
---|---|
Тема | Re: public schema default ACL |
Дата | |
Msg-id | CA+Tgmob9=HeiLaKzYhxqkjQEOJgcvmfVAFsL9+7RVhhJ1fshEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: public schema default ACL (Stephen Frost <sfrost@snowman.net>) |
Список | 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 по дате отправления: