From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Marc Munro <marc(at)bloodnok(dot)com>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using views for row-level access control is leaky |
Date: | 2009-10-23 11:30:13 |
Message-ID: | 4AE193C5.3000204@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> Also, we should presume that any function created with SECURITY DEFINER
> and created by a superuser would have plan security, so we don't need to
> annotate lots of old code to work securely. Annotating the built-in
> functions is a lot easier.
SECURITY DEFINER is an orthogonal aspect. Consider something as
innocent-looking as this:
CREATE FUNCTION secdeffunc(text) RETURNS boolean AS $$ SELECT
$1::integer < 10; $$ LANGUAGE SQL SECURITY DEFINER;
The text-to-integer cast throws an error and reveals the argument as
someone pointed out earlier in this thread. Creating such a function
shouldn't open the door to information leaks in views elsewhere.
The most useful "automatic" annotation I can see is to treat functions
implementing B-tree operators as safe. I *think* that's safe, anyway.
>> 2. If the view refers only one table (as a typical Veil view does), plan
>> it like we do today but enforce that view conditions are evaluated first
>> in the Filter. Notably, allow using any user-supplied conditions as
>> index quals if there's a matching index.
>>
>> 3. Otherwise fully materialize the view.
>
> So if we join a normal table or a view to a secure view then only the
> secure view part would be materialized? Or do you mean the whole query
> would be materialized?
Just the secure view. Materializing the result of the overall query
wouldn't help.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-10-23 11:40:03 | Re: Using views for row-level access control is leaky |
Previous Message | KaiGai Kohei | 2009-10-23 11:19:12 | Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363)) |