Re: Add pg_file_sync() to adminpack - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Add pg_file_sync() to adminpack
Date
Msg-id CAOBaU_Y1MYUUqT01XOdAnCBP01ALKFxhrZT87QiCuLkbr2EC-w@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_file_sync() to adminpack  (Atsushi Torikoshi <atorik@gmail.com>)
Responses Re: Add pg_file_sync() to adminpack  (Atsushi Torikoshi <atorik@gmail.com>)
List pgsql-hackers
On Tue, Jan 14, 2020 at 4:08 PM Atsushi Torikoshi <atorik@gmail.com> wrote:
>
> > On Sut, Jan 11, 2020 at  2:12 Fujii Masao <masao.fujii@gmail.com>:
> > > But pg_write_server_files users are not allowed to execute
> > > other functions like pg_file_write() by default. So doing that
> > > change only for pg_file_sync() looks strange to me.
>
> > Ah indeed.  I'm wondering if that's an oversight of the original
> > default role patch or voluntary.
>
> It's not directly related to the patch, but as far as I read the
> manual below, I expected pg_write_server_files users could execute
>  adminpack functions.
>
>   | Table 21.1 Default Roles
>   | pg_write_server_files: Allow writing to files in any location the database can access on the server with COPY and
otherfile-access functions.
 

Actually, pg_write_server_files has enough privileges to execute those
functions anywhere on the FS as far as C code is concerned, provided
that the user running postgres daemon is allowed to (see
convert_and_check_filename), but won't be allowed to do so by default
as it won't have EXECUTE privilege on the functions.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: our checks for read-only queries are not great
Next
From: Robert Haas
Date:
Subject: Re: backup manifests