Simon Riggs wrote:
On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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,
party_id,
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
2009/10/23 Simon Riggs si...@2ndquadrant.com:
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
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.
For me,
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 lot
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-in
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
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
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 generate
Simon Riggs si...@2ndquadrant.com 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
On Fri, Oct 23, 2009 at 10:04:29AM -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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
David Fetter da...@fetter.org 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
On Fri, 2009-10-23 at 10:04 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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
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;
END; $$
What version do you have?
I am cannot repeat it.
Regards
Pavel Stehule
2009/10/22 Richard Huxton d...@archonet.com:
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
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 d...@archonet.com:
Heikki Linnakangas wrote:
CREATE VIEW phone_number AS
SELECT
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;
$$
2009/10/22 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
That example I ran on CVS HEAD, but it's a generic problem on all versions.
postgres=# select version();
version
Pavel Stehule wrote:
2009/10/22 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
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: %', person, phone;
2009/10/22 Richard Huxton d...@archonet.com:
Pavel Stehule wrote:
2009/10/22 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
That example I ran on CVS HEAD, but it's a generic problem on all versions.
postgres=# select version();
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)
still I have
On Thu, Oct 22, 2009 at 6:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
\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(person, phone);
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
28 matches
Mail list logo
