Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file?
От | hubert depesz lubaczewski |
---|---|
Тема | Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file? |
Дата | |
Msg-id | ZBMD6E3oRGDJZ0Sd@depesz.com обсуждение исходный текст |
Ответ на | Re: pg_read_server_files doesn't let me use pg_ls_dir() or pg_read_file? (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-bugs |
On Thu, Mar 16, 2023 at 10:11:04AM +0900, Kyotaro Horiguchi wrote: > 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. Ok, tested. You're right. So it was my misunderstanding. Could be that the docs could use some clarification, but otoh, it could be just as well that I suck at understanding :) Thanks a lot for the info. Best regards, depesz
В списке pgsql-bugs по дате отправления: