leaky views, yet again
in [PgSql]
|
From: KaiGai Kohei on 8 Jul 2010 23:47 (2010/07/08 22:08), Robert Haas wrote: > I think we pretty much have conceptual agreement on the shape of the > solution to this problem: when a view is created with CREATE SECURITY > VIEW, restrict functions and operators that might disclose tuple data > from being pushed down into view (unless, perhaps, the user invoking > the view has sufficient privileges to execute the underlying query > anyhow, e.g. superuser or view owner). What we have not resolved is > exactly how we're going to decide which functions and operators might > do such a dastardly thing. I think the viable options are as follows: > > 1. Adopt Heikki's proposal of treating indexable operators as non-leaky. > > http://archives.postgresql.org/pgsql-hackers/2010-06/msg00291.php > > Or, perhaps, and even more restrictively, treat only > hashable/mergeable operators as non-leaky. > > 2. Add an explicit flag to pg_proc, which can only be set by > superusers (and which is cleared if a non-superuser modifies it in any > way), allowing a function to be tagged as non-leaky. I believe that > it would be reasonable to set this flag for all of our built-in > indexable operators (though I'd read the code before doing it), but it > would remove the need for the assumption that third-party operators > are equally sane. > > CREATE OR REPLACE FUNCTION doesnt_leak() RETURNS integer AS $$SELECT > 42$$ IMMUTABLE SEAWORTHY; -- doesn't leak > > This problem is not going away, so we should try to decide on something. > I'd like to vote the second option, because this approach will be also applied on another aspect of leaky views. When leaky and non-leaky functions are chained within a WHERE clause, it will be ordered by the cost of functions. So, we have possibility that leaky functions are executed earlier than non-leaky functions. It will not be an easy work to mark built-in functions as either leaky or non-leaky, but it seems to me the most straight forward solution. Thanks, -- 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: Robert Haas on 19 Jul 2010 13:08 2010/7/8 KaiGai Kohei <kaigai(a)ak.jp.nec.com>: > (2010/07/08 22:08), Robert Haas wrote: >> I think we pretty much have conceptual agreement on the shape of the >> solution to this problem: when a view is created with CREATE SECURITY >> VIEW, restrict functions and operators that might disclose tuple data >> from being pushed down into view (unless, perhaps, the user invoking >> the view has sufficient privileges to execute the underlying query >> anyhow, e.g. superuser or view owner). �What we have not resolved is >> exactly how we're going to decide which functions and operators might >> do such a dastardly thing. �I think the viable options are as follows: >> >> 1. Adopt Heikki's proposal of treating indexable operators as non-leaky. >> >> http://archives.postgresql.org/pgsql-hackers/2010-06/msg00291.php >> >> Or, perhaps, and even more restrictively, treat only >> hashable/mergeable operators as non-leaky. >> >> 2. Add an explicit flag to pg_proc, which can only be set by >> superusers (and which is cleared if a non-superuser modifies it in any >> way), allowing a function to be tagged as non-leaky. �I believe that >> it would be reasonable to set this flag for all of our built-in >> indexable operators (though I'd read the code before doing it), but it >> would remove the need for the assumption that third-party operators >> are equally sane. >> >> CREATE OR REPLACE FUNCTION doesnt_leak() RETURNS integer AS $$SELECT >> 42$$ IMMUTABLE SEAWORTHY; -- doesn't leak >> >> This problem is not going away, so we should try to decide on something. >> > I'd like to vote the second option, because this approach will be also > applied on another aspect of leaky views. > > When leaky and non-leaky functions are chained within a WHERE clause, > it will be ordered by the cost of functions. So, we have possibility > that leaky functions are executed earlier than non-leaky functions. > > It will not be an easy work to mark built-in functions as either leaky > or non-leaky, but it seems to me the most straight forward solution. Does anyone else have an opinion on this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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: Heikki Linnakangas on 19 Jul 2010 13:13 On 09/07/10 06:47, KaiGai Kohei wrote: > When leaky and non-leaky functions are chained within a WHERE clause, > it will be ordered by the cost of functions. So, we have possibility > that leaky functions are executed earlier than non-leaky functions. No, that needs to be forbidden as part of the fix. Leaky functions must not be executed before all the quals from the view are evaluated. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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: Heikki Linnakangas on 19 Jul 2010 13:19 On 19/07/10 20:08, Robert Haas wrote: > 2010/7/8 KaiGai Kohei<kaigai(a)ak.jp.nec.com>: >> (2010/07/08 22:08), Robert Haas wrote: >>> I think we pretty much have conceptual agreement on the shape of the >>> solution to this problem: when a view is created with CREATE SECURITY >>> VIEW, restrict functions and operators that might disclose tuple data >>> from being pushed down into view (unless, perhaps, the user invoking >>> the view has sufficient privileges to execute the underlying query >>> anyhow, e.g. superuser or view owner). What we have not resolved is >>> exactly how we're going to decide which functions and operators might >>> do such a dastardly thing. I think the viable options are as follows: >>> >>> 1. Adopt Heikki's proposal of treating indexable operators as non-leaky. >>> >>> http://archives.postgresql.org/pgsql-hackers/2010-06/msg00291.php >>> >>> Or, perhaps, and even more restrictively, treat only >>> hashable/mergeable operators as non-leaky. >>> >>> 2. Add an explicit flag to pg_proc, which can only be set by >>> superusers (and which is cleared if a non-superuser modifies it in any >>> way), allowing a function to be tagged as non-leaky. I believe that >>> it would be reasonable to set this flag for all of our built-in >>> indexable operators (though I'd read the code before doing it), but it >>> would remove the need for the assumption that third-party operators >>> are equally sane. >>> >>> CREATE OR REPLACE FUNCTION doesnt_leak() RETURNS integer AS $$SELECT >>> 42$$ IMMUTABLE SEAWORTHY; -- doesn't leak >>> >>> This problem is not going away, so we should try to decide on something. >>> >> I'd like to vote the second option, because this approach will be also >> applied on another aspect of leaky views. >> >> When leaky and non-leaky functions are chained within a WHERE clause, >> it will be ordered by the cost of functions. So, we have possibility >> that leaky functions are executed earlier than non-leaky functions. >> >> It will not be an easy work to mark built-in functions as either leaky >> or non-leaky, but it seems to me the most straight forward solution. > > Does anyone else have an opinion on this? I have a bad feeling that marking functions explicitly as seaworthy is going to be hard to get right, and every time you get that wrong it's a security issue. On the other hand, if it's enough from a performance point of view to review and mark only a few built-in functions like index operators, maybe it's ok. It would be easier to assess this if we had a patch to play with that contained all the planner changes to keep track of the seaworthiness of functions and apply the quals in right order. You could then try out different scenarios to see what the performance is like. I guess what I'm saying is "write a patch, and I'll shoot it down when you're done" :-/. But hopefully the planner changes don't depend much on how we deduce which quals are leaky. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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: Robert Haas on 19 Jul 2010 13:47 On Mon, Jul 19, 2010 at 1:19 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > I guess what I'm saying is "write a patch, and I'll shoot it down when > you're done" :-/. But hopefully the planner changes don't depend much on how > we deduce which quals are leaky. Oh, great... I love that. /me rolls eyes -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: inner join removal Next: [HACKERS] Branch created, let the experiment begin ... |