Re: How easy is it to lose permissions in 'public' schema?
От | Adrian Klaver |
---|---|
Тема | Re: How easy is it to lose permissions in 'public' schema? |
Дата | |
Msg-id | d81bd77e-be7f-0b53-1089-882ce2edf0ac@aklaver.com обсуждение исходный текст |
Ответ на | Re: How easy is it to lose permissions in 'public' schema? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: How easy is it to lose permissions in 'public' schema?
|
Список | pgsql-general |
On 4/11/22 17:34, Tom Lane wrote: > Adrian Klaver <adrian.klaver@aklaver.com> writes: >> On 4/11/22 16:10, Rob Sargent wrote: >>> I've just bumped into this. >>> >>> barnard=> select public.genome_threshold_mono('a'::text,'b'::text); >>> ERROR: permission denied for schema public >>> LINE 1: select public.genome_threshold_mono('a'::text,'b'::text); >>> >>> I know I haven't intentionally removed 'public' from grantee's purview >>> and short of the code block above not actually getting run, any guesses >>> as to how access to 'public' got removed from grantee? > >> I'm going to say someone read this: >> https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path >> And did something along the line of this: >> REVOKE CREATE ON SCHEMA public FROM PUBLIC; > > Note that that only recommends removing CREATE, though, not USAGE > which is what Rob seems to be lacking. Yeah that is why I threw in the 'And did something along the line of this' and the 'Probably should take a look at what permissions the functions in public have?'. I'm guessing someone saw the release notes for 10.3(https://www.postgresql.org/docs/10/release-10-3.html) and the comments on the mailing list and got proactive. > > regards, tom lane -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: