Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file?
От | Kyotaro Horiguchi |
---|---|
Тема | Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file? |
Дата | |
Msg-id | 20230316.101104.634148126391618068.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file? (hubert depesz lubaczewski <depesz@depesz.com>) |
Ответы |
Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file?
|
Список | pgsql-bugs |
At Wed, 15 Mar 2023 11:46:17 +0100, hubert depesz lubaczewski <depesz@depesz.com> wrote in > On Wed, Mar 15, 2023 at 11:10:11AM +0900, Kyotaro Horiguchi wrote: > > At Tue, 14 Mar 2023 20:33:10 +0100, hubert depesz lubaczewski <depesz@depesz.com> wrote > > OK, I get it, but then, what is the point of mentioning > pg_read_server_files in the doc? I can just as well grant execute on the > functions to someone. And, I tested, they don't need to be in > pg_read_server_files. I believe you can confirm that the non-superuser test cannot access /etc without the pg_read_server_files privilege. > postgres=> select * from pg_ls_dir('/etc'); > ERROR: absolute path not allowed > postgres=> select * from pg_ls_dir('../../'); > ERROR: path must be in or below the current directory ("current" directory...) Although the order of the descriptions may seem reversed, the doc clearly states that pg_read_server_files is responsible for controlling access outside the database cluster directory and the log_directory for non-superusers, while GRANT EXECUTE regulates executability for non-superusers. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: