Largeobject Access Controls (r2460)
in [PgSql]
|
Prev: explain output infelicity in psql
Next: Winflex
From: Tom Lane on 10 Dec 2009 23:23 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > OK, I'll add the following description in the documentation of pg_largeobject. > <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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 10 Dec 2009 23:57 Tom Lane wrote: > Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: >> OK, I'll add the following description in the documentation of pg_largeobject. > >> <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? 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. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 11 Dec 2009 00:10 2009/12/10 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > > 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. > it doesn't seem like a good idea to make that GUC act like a GRANT or REVOKE on the case of pg_largeobject. besides if a normal user can read from pg_class why we deny pg_largeobject -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 11 Dec 2009 00:17 KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote: > Tom Lane wrote: > > Takahiro Itagaki <itagaki.takahiro(a)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; 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. > 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" ? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 11 Dec 2009 00:24
Takahiro Itagaki wrote: > KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote: > >> Tom Lane wrote: >>> Takahiro Itagaki <itagaki.takahiro(a)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(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |