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.
Please wait for a while.
>> If so, we can inject a hardwired rule to prevent to select pg_largeobject
>> when lo_compat_privileges is turned off, instead of REVOKE ALL FROM PUBLIC.
>
> Is it enough to run "GRANT SELECT ON pg_largeobject TO PUBLIC" ?
Agreed.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
