Simon Riggs wrote:
> On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
> > Simon Riggs writes:
> > > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> > >> Sorry, what is happen if function is marked as "plan security"?
> >
> > > I was suggesting an intelligent default by which we could d
On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> >> Sorry, what is happen if function is marked as "plan security"?
>
> > I was suggesting an intelligent default by which we could determine
> > function marking i
David Fetter wrote:
> One of the things the security community has learned is that the
> only way it's even possible to get an information leak rate of zero
> is to have a system which does nothing at all. It's a fact we need
> to bear in mind when addressing this or any other issue of access
>
Tom Lane wrote:
> The thought that's been in the back of my mind is that you could solve
> 99% of the performance problem if you trusted all builtin functions and
> nothing else. This avoids the question of who gets to mark functions
> as trustable.
Except that all builtin functions are not trust
On Fri, Oct 23, 2009 at 10:04:29AM -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
> >> Sorry, what is happen if function is marked as "plan security"?
>
> > I was suggesting an intelligent default by which we could
> > determine function ma
Simon Riggs writes:
> On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei wrote:
>> Sorry, what is happen if function is marked as "plan security"?
> I was suggesting an intelligent default by which we could determine
> function marking implicitly, if it was not explicitly stated on the
> CREATE FUNC
Heikki Linnakangas wrote:
> The most useful "automatic" annotation I can see is to treat functions
> implementing B-tree operators as safe. I *think* that's safe, anyway.
Index lookups and single-type comparisons were the only things I could
come up with as safe. Unless there is some way to genera
Rod Taylor wrote:
> This still allow many optimizations to be applied in complex cases. The
> planner
>
> CREATE VIEW phone_number AS
> SELECT person, phone, company
> FROM phone_data USING SECURITY FILTER(phone NOT LIKE '6%')
>JOIN person USING (person_id)
>JOIN company USING (co
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 orthogon
Simon Riggs wrote:
> On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei 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-i
On Fri, 2009-10-23 at 19:38 +0900, KaiGai Kohei 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
Simon Riggs wrote:
> On Fri, 2009-10-23 at 11:30 +0300, Heikki Linnakangas wrote:
>
>> The most user-friendly and backwards-compatible (though not necessarily
>> back-patchable) approach I can see is:
>>
>> 1. If the user has read access to all the underlying tables, plan it
>> like we do today.
>
2009/10/23 Simon Riggs :
> On Fri, 2009-10-23 at 11:30 +0300, Heikki Linnakangas wrote:
>
>> The most user-friendly and backwards-compatible (though not necessarily
>> back-patchable) approach I can see is:
>>
>> 1. If the user has read access to all the underlying tables, plan it
>> like we do tod
On Fri, 2009-10-23 at 11:30 +0300, Heikki Linnakangas wrote:
> The most user-friendly and backwards-compatible (though not necessarily
> back-patchable) approach I can see is:
>
> 1. If the user has read access to all the underlying tables, plan it
> like we do today.
For me, it would make most
Marc Munro wrote:
> Here is a typical veil secured view definition:
>
> create view parties as
> SELECT party_id, client_id, party_type_id, username, party_name
> FROM parties.parties
> WHERE api.user_has_client_or_personal_privilege(client_id,
> par
Just to intoduce myself, I'm Marc Munro the developer of Veil, a
postgres add-in that allows you to implement virtual private databases
using views.
The problem we are discussing here is the existence of covert or
side-channels being available from functions that can leak information
about the row
>
> \c - secretary
>
> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
> RETURNS bool AS $$
> begin
> RAISE NOTICE 'person: % number: %', person, phone;
> RETURN true;
> END; $$ LANGUAGE plpgsql COST 0.01;
>
> postgres=> SELECT * FROM phone_number WHERE expose_person(perso
On Thu, Oct 22, 2009 at 6:03 AM, Heikki Linnakangas
wrote:
> In chapter "36.4 Rules and Privileges" we show an example of using a
> view to expose part of a table to other users, keeping other rows private:
>
>> For example: A user has a list of phone numbers where some of them are
> private, the
Pavel Stehule wrote:
>
> postgres=# create or replace function vv(int, int) returns bool as
> $$begin raise notice '% %', $1, $2; return true; end$$ language
> plpgsql COST 0.01;
> CREATE FUNCTION
> postgres=# select * from v where vv(a,b);NOTICE: 10 20
> a │ b
> ───┼───
> (0 rows)
>
> stil
2009/10/22 Richard Huxton :
> Pavel Stehule wrote:
>> 2009/10/22 Heikki Linnakangas :
>>> That example I ran on CVS HEAD, but it's a generic problem on all versions.
>> postgres=# select version();
>> version
>>
Richard Huxton wrote:
> Heikki Linnakangas wrote:
>> CREATE VIEW phone_number AS
>> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
>
>> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
>> RETURNS bool AS $$
>> begin
>> RAISE NOTICE 'person: % number: %', pe
Pavel Stehule wrote:
> 2009/10/22 Heikki Linnakangas :
>> That example I ran on CVS HEAD, but it's a generic problem on all versions.
> postgres=# select version();
>version
> ───
2009/10/22 Heikki Linnakangas :
> That example I ran on CVS HEAD, but it's a generic problem on all versions.
postgres=# select version();
version
PostgreSQL 8.5d
Pavel Stehule wrote:
> What version do you have?
>
> I am cannot repeat it.
It will depend on the relative cost of the clauses (though 0.0001 should
have been enough to force it). Try:
CREATE OR REPLACE FUNCTION row_hidden (phone text) RETURNS bool AS $$
BEGIN
RETURN phone LIKE '6%';
END;
$$
That example I ran on CVS HEAD, but it's a generic problem on all versions.
Pavel Stehule wrote:
> What version do you have?
>
> I am cannot repeat it.
>
> Regards
> Pavel Stehule
>
> 2009/10/22 Richard Huxton :
>> Heikki Linnakangas wrote:
>>> CREATE VIEW phone_number AS
>>> SELECT person,
What version do you have?
I am cannot repeat it.
Regards
Pavel Stehule
2009/10/22 Richard Huxton :
> Heikki Linnakangas wrote:
>> CREATE VIEW phone_number AS
>> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
>
>> CREATE OR REPLACE FUNCTION expose_person (person text, phone t
Heikki Linnakangas wrote:
> CREATE VIEW phone_number AS
> SELECT person, phone FROM phone_data WHERE phone NOT LIKE '6%';
> CREATE OR REPLACE FUNCTION expose_person (person text, phone text)
> RETURNS bool AS $$
> begin
> RAISE NOTICE 'person: % number: %', person, phone;
> RETURN true;
>
In chapter "36.4 Rules and Privileges" we show an example of using a
view to expose part of a table to other users, keeping other rows private:
> For example: A user has a list of phone numbers where some of them are
private, the others are of interest for the secretary of the office. He
can const
28 matches
Mail list logo
