Greetings, * Gilles Darold (gil...@darold.net) wrote: > Le 28/08/2020 à 15:26, Stephen Frost a écrit : > >* Magnus Hagander (mag...@hagander.net) wrote: > >>On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost <sfr...@snowman.net> wrote: > >>>* Magnus Hagander (mag...@hagander.net) wrote: > >>>>Without having actually looked at the code, definite +1 for this feature. > >>>>It's much requested... > >>>Thanks. > >>> > >>>>But, should we also have a pg_write_all_data to go along with it? > >>>Perhaps, but could certainly be a different patch, and it'd need to be > >>>better defined, it seems to me... read_all is pretty straight-forward > >>>(the general goal being "make pg_dumpall/pg_dump work"), what would > >>>write mean? INSERT? DELETE? TRUNCATE? ALTER TABLE? System catalogs? > >>Well, it's pg_write_all_*data*, so it certainly wouldn't be alter table or > >>system catalogs. > >> > >>I'd say insert/update/delete yes. > >> > >>TRUNCATE is always an outlier.Given it's generally classified as DDL, I > >>wouldn't include it. > >Alright, that seems like it'd be pretty easy. We already have a check > >in pg_class_aclmask to disallow modification of system catalogs w/o > >being a superuser, so we should be alright to add a similar check for > >insert/update/delete just below where I added the SELECT check. > > > >>>Doesn't seem like you could just declare it to be 'allow pg_restore' > >>>either, as that might include creating untrusted functions, et al. > >>No definitely not. That wouldn't be the usecase at all :) > >Good. :) > > > >>(and fwiw to me the main use case for read_all_data also isn't pg_dump, > >>because most people using pg_dump are already db owner or higher in my > >>experience. But it is nice that it helps with that too) > >Glad to have confirmation that there's other use-cases this helps with. > > > >I'll post an updated patch with that added in a day or two. > > Looking at this thread I was thinking about the FDW. Does role > pg_read_all_data will allow to execute pg_dump with --include-foreign-data > option? If this is the case how about priviledge on fdw and foreign server? > If this is the behavior we want I guess that the modification should be > applied to pg_foreign_data_wrapper_aclmask() and pg_foreign_server_aclmask() > too.
Using an FDW will often also require having a user mapping and there's no way for that to be accomplished through only GRANT'ing a default role, so I don't think we should mix this specific role with the FDW permissions system. Thanks, Stephen
signature.asc
Description: PGP signature