KaiGai Kohei wrote: > Takahiro Itagaki wrote: > > KaiGai Kohei <kai...@ak.jp.nec.com> wrote: > > > >> Tom Lane wrote: > >>> Takahiro Itagaki <itagaki.takah...@oss.ntt.co.jp> writes: > >>>> <structname>pg_largeobject</structname> should not be readable by the > >>>> public, since the catalog contains data in large objects of all users. > >>> This is going to be a problem, because it will break applications that > >>> expect to be able to read pg_largeobject. Like, say, pg_dump. > >> Is it a right behavior, even if we have permission checks on large objects? > > > > Can we use column-level access control here? > > > > REVOKE ALL ON pg_largeobject FROM PUBLIC; > > => GRANT SELECT (loid) ON pg_largeobject TO PUBLIC; > > Indeed, it seems to me reasonable. > > > We use "SELECT loid FROM pg_largeobject LIMIT 1" in pg_dump. We could > > replace pg_largeobject_metadata instead if we try to fix only pg_dump, > > but it's no wonder that any other user applications use such queries. > > I think to allow reading loid is a balanced solution. > > Right, I also remind this query has to be fixed up by other reason right now. > If all the large objects are empty, this query can return nothing, even if > large object entries are in pg_largeobject_metadata.
"metadata" seems very vague. Can't we come up with a more descriptive name? Also, how will this affect pg_migrator? pg_migrator copies pg_largeobject and its index from the old to the new server. Is the format inside pg_largeobject changed by this patch? What happens when there is no entry in pg_largeobject_metadata for a specific row? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
