Re: Largeobject Access Controls (r2460)
От | KaiGai Kohei |
---|---|
Тема | Re: Largeobject Access Controls (r2460) |
Дата | |
Msg-id | 4B226C48.1000201@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: Largeobject Access Controls (r2460) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Largeobject Access Controls (r2460)
|
Список | pgsql-hackers |
Bruce Momjian さんは書きました: > KaiGai Kohei wrote: >> Takahiro Itagaki wrote: >>> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote: >>> >>>> Tom Lane wrote: >>>>> Takahiro Itagaki <itagaki.takahiro@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? What about "property"? The "metadata" was the suggested name from Robert Haas at the last commit fest, because we may store any other properties of a large object in this catalog future. > 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? The format of pg_largeobject was not touched. > What happens when > there is no entry in pg_largeobject_metadata for a specific row? In this case, these rows become orphan. So, I think we need to create an empty large object with same LOID on pg_migrator. It makes an entry on pg_largeobject_metadata without writing anything to the pg_largeobject. I guess rest of migrations are not difference. Correct? Thanks,
В списке pgsql-hackers по дате отправления: