On Wed, Oct 20, 2010 at 10:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> I get the impression that you think that there's a problem not only
>> with the approach but with any approach whatsoever to that underlying
>> problem.
>
> Let's just say that the approaches proposed so far have performan
Robert Haas writes:
> I get the impression that you think that there's a problem not only
> with the approach but with any approach whatsoever to that underlying
> problem.
Let's just say that the approaches proposed so far have performance
and/or functionality and/or code maintenance penalties t
On Wed, Oct 13, 2010 at 12:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
>>> That's all true, but you have to consider how much the obstacle actually
>>> gets in their way versus how painful it is on your end to create and
>>> maintain the obst
KaiGai Kohei writes:
> (2010/10/19 21:31), Robert Haas wrote:
>> I think you're still misreading it.
> Hmm. In my understanding, it seems to me he concerned about possible leaky
> estimate functions, so he mentioned the horrible performance degrading, if
> we don't allow to execute these function
(2010/10/19 21:31), Robert Haas wrote:
On Oct 19, 2010, at 4:34 AM, KaiGai Kohei wrote:
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way vers
On Oct 19, 2010, at 4:34 AM, KaiGai Kohei wrote:
> (2010/10/14 1:52), Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your end to create and
maintain the obstacle. �I don't think this pro
On Mon, Oct 18, 2010 at 5:02 AM, KaiGai Kohei wrote:
>> Just to give one example of what this patch misses (probably; as I said
>> I haven't read it lately), what about selectivity estimation? One of
>> the things we like to do when we have an otherwise-unknown function is
>> to try it on all the
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your end to create and
maintain the obstacle. �I don't think this pro
Tom Lane wrote:
> the "OMG Postgres exposes my information" crowd is not going to
> distinguish leaks that only expose MCVs from those that trivially
> allow sucking out the entire table.
Well, I'd be in the crowd that would go "OMG" over one but not the
other. At least in our case management
Robert Haas writes:
> You seem to believe that being able to infer the total size of a
> table or the frequency of some particular key in the table is
> equivalent to being able to trivially read every row of it.
I don't say that they're equivalent. I do say that what this patch is
mostly trying
Robert Haas writes:
> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
>> That's all true, but you have to consider how much the obstacle actually
>> gets in their way versus how painful it is on your end to create and
>> maintain the obstacle. I don't think this proposed patch measures up
>> v
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
>> ACM luncheon once. When she discussed security, she asserted that
>> there was no such thing as security which could not be breached.
>> The goal o
On Wed, Oct 13, 2010 at 9:43 AM, Tom Lane wrote:
> Robert Haas writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EX
"Kevin Grittner" writes:
> I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
> ACM luncheon once. When she discussed security, she asserted that
> there was no such thing as security which could not be breached.
> The goal of security efforts should not be to make it perfect,
> b
KaiGai Kohei wrote:
> Previous security researcher pointed out security is trading-off,
> not all-or-nothing. If we can plug most part of the threat with
> reasonable performance degrading, it is worthwhile to fix up.
I had the pleasure of hearing Admiral Grace Hopper[1] speak at an
ACM lunche
(2010/10/13 22:43), Tom Lane wrote:
> Robert Haas writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EXPLAIN output o
Robert Haas writes:
> With the possible exception of Tom,
> everyone seems to agree that it would be a good step forward to
> provide a way of plugging these holes, even if it didn't cover subtler
> information leaks such as by reading the EXPLAIN output or timing
> query execution.
> 1. Does any
2010/10/12 KaiGai Kohei :
> I noticed the previous patch has an obvious conflict to the latest
> git mater, and it does not have any documentation updates.
>
> So, I rebased the patch, and added descriptions about secure views.
> Rest of parts are unchanged.
It seems that we have rough agreement t
Hi,
Stephen Frost writes:
> Wow, I just kind of assumed you could; I'm not really sure why. Perhaps
> it'll be possible in the future though, so might be something to think
> about if/when it happens. Can't see a way to abuse the view from inside
> a DO or in a function in the same way either.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2010 at 9:10 AM, Stephen Frost wrote:
> > This might be overly pedantic, but I don't think 'tampering' gives the
> > right impression.
>
> I'm open to suggestions.
Yeah, wasn't coming up with a better word myself. :/ Maybe something
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> On 07.10.2010 16:10, Stephen Frost wrote:
>> Also, even if you can't create functions (due to lack of create
>> privileges on any schema), you could use DO clauses now.
>
> There's no way to shoehorn a DO clause into a SELECT, you
On Thu, Oct 7, 2010 at 9:10 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Oct 7, 2010 at 2:02 AM, Heikki Linnakangas
>> > Looks good. It gives the impression that you need to be able to a create
>> > custom function to exploit, though. It would be good to menti
On 07.10.2010 16:10, Stephen Frost wrote:
Also, even if you can't create functions (due to lack of create
privileges on any schema), you could use DO clauses now.
There's no way to shoehorn a DO clause into a SELECT, you can't do:
SELECT data FROM view WHERE (DO $$ RAISE NOTICE argument; $$) =
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 7, 2010 at 2:02 AM, Heikki Linnakangas
> > Looks good. It gives the impression that you need to be able to a create
> > custom function to exploit, though. It would be good to mention that
> > internal functions can be used too, revoking ac
On Thu, Oct 7, 2010 at 2:02 AM, Heikki Linnakangas
wrote:
> On 07.10.2010 06:39, Robert Haas wrote:
>>
>> On Tue, Oct 5, 2010 at 3:42 PM, Tom Lane wrote:
>>>
>>> Right, *column* filtering seems easy and entirely secure. The angst
>>> here is about row filtering. Can we have a view in which user
On 07.10.2010 06:39, Robert Haas wrote:
On Tue, Oct 5, 2010 at 3:42 PM, Tom Lane wrote:
Right, *column* filtering seems easy and entirely secure. The angst
here is about row filtering. Can we have a view in which users can see
the values of a column for some rows, with perfect security that t
On Tue, Oct 5, 2010 at 3:42 PM, Tom Lane wrote:
> Right, *column* filtering seems easy and entirely secure. The angst
> here is about row filtering. Can we have a view in which users can see
> the values of a column for some rows, with perfect security that they
> can't identify values for the h
(2010/10/06 4:15), Heikki Linnakangas wrote:
On 05.10.2010 21:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built
(2010/10/06 4:06), Robert Haas wrote:
> On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
>>
>
bricklen wrote:
> Kevin Grittner wrote:
>> Right now this is managed by query classes in our Java
>> applications, but as we're moving to a variety of new and
>> different technologies it's getting harder for the DBAs to ensure
>> that nothing is leaking to inappropriate recipients. :-( I
>> th
bricklen writes:
> Does Veil cover some of those needs?
> http://veil.projects.postgresql.org/curdocs/index.html
This entire discussion arose from the desire to plug the holes in Veil...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Tue, Oct 5, 2010 at 4:25 PM, Kevin Grittner
wrote:
>> The stronger form is that they shouldn't even be able to tell that
>> hidden rows exist, which is something your view doesn't try to do;
>> but there are at least some applications where that would be
>> desirable.
>
> I can understand that,
On Tue, Oct 5, 2010 at 1:25 PM, Kevin Grittner
wrote:
> Right now this is managed by query classes in our Java applications,
> but as we're moving to a variety of new and different technologies
> it's getting harder for the DBAs to ensure that nothing is leaking
> to inappropriate recipients. :-(
Tom Lane wrote:
> Well, the approach you suggested of putting a security wrapper
> around the output column might be bulletproof against that; I'm
> not entirely sure, but I don't see a hole in it at the moment.
> The trouble with it is that it's pretty bad from a performance
> point of view, a
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I don't believe we can solve Kevin's version of the problem, which
>> is whether a stalker can verify the address of a victim that he's
>> not supposed to be able to see.
> I'm surprised; I thought that we were already there.
Well, the approach you
Tom Lane wrote:
> I don't believe we can solve Kevin's version of the problem, which
> is whether a stalker can verify the address of a victim that he's
> not supposed to be able to see.
I'm surprised; I thought that we were already there. If someone has
SELECT rights on that view, how would
On 05.10.2010 21:48, Tom Lane wrote:
Heikki Linnakangas writes:
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built-in functions for leaking data as well.
The
On Tue, Oct 5, 2010 at 2:48 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 05.10.2010 21:08, Greg Stark wrote:
>>> If the users that have select access on the view don't have DDL access
>>> doesn't that make them leak-proof for those users?
>
>> No. You can use built-in functions for leak
On Tue, 2010-10-05 at 14:49 -0400, Robert Haas wrote:
> On Tue, Oct 5, 2010 at 2:08 PM, Greg Stark wrote:
> > Though I find it unlikely the sales people would have direct access to
> > run arbitrary SQL -- let alone create custom functions.
>
> I have definitely seen shops where virtually everyon
On Tue, Oct 5, 2010 at 2:08 PM, Greg Stark wrote:
> Though I find it unlikely the sales people would have direct access to
> run arbitrary SQL -- let alone create custom functions.
I have definitely seen shops where virtually everyone has SQL-level
access to the database. Several of them. Most
Heikki Linnakangas writes:
> On 05.10.2010 21:08, Greg Stark wrote:
>> If the users that have select access on the view don't have DDL access
>> doesn't that make them leak-proof for those users?
> No. You can use built-in functions for leaking data as well.
There's a difference between "can be
Robert Haas writes:
> ... I agree it's hopeless to
> prevent all side-channel leaks, but I'd describe the goal like this:
> Prevent access to the actual tuple contents of the hidden rows.
> Failing to solve this problem at the database level doesn't remove the
> business requirement. I've solve
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built-in functions for leaking data as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
* Greg Stark (gsst...@mit.edu) wrote:
> Though I find it unlikely the sales people would have direct access to
> run arbitrary SQL -- let alone create custom functions.
I'm not really sure why..? Perhaps not quite the same, but I've got
quite a few users who have direct SQL access (though they us
On Tue, Oct 5, 2010 at 11:01 AM, Robert Haas wrote:
> Well, the only thing I've ever wanted to do this for was to allow
> sales reps to see their own customers but not the customers of other
> sales reps (because if they could pull our complete customer list,
> then once they left and went to work
On Tue, Oct 5, 2010 at 1:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>>> That doesn't make permissions on them useless, so you're attacking a
>>> straw man.
>
>> Really? I'm confused. What is the use case for the status quo?
>
> Access to ta
Robert Haas wrote:
> What is the use case for the status quo?
Much simplified:
create table party
(
countyno smallint not null,
caseno varchar(14) not null,
partyno smallint not null,
name text not null,
address text,
isaddrsealed boolean not null,
primary key (countyno, caseno,
Robert Haas writes:
> On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>> That doesn't make permissions on them useless, so you're attacking a
>> straw man.
> Really? I'm confused. What is the use case for the status quo?
Access to tables that you have no direct privileges on, mainly.
(This i
On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane wrote:
>> Option #1: Remove all mention from the documentation of using views
>> for security purposes. Don't allow views to have explicit permissions
>> attached to them; they are merely shorthand for a SELECT, for which
>> you either do or do not have p
On Tue, 2010-10-05 at 12:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
> >> Personally I think this is a dead end that we shouldn't be wasting
> >> any more time on.
>
> > But you haven't proposed a reasonable alternative.
>
> Tom: "This pr
Robert Haas writes:
> On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
>> Personally I think this is a dead end that we shouldn't be wasting
>> any more time on.
> But you haven't proposed a reasonable alternative.
Tom: "This problem is insoluble."
Robert: "You can't claim that without offering
(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas writes:
>>> Checking the functions of the operators is the right thing to do, but
>>> assuming that internal = safe does not work. For example, pushing
>>> down arithmetic operators allows you to probe fo
(2010/10/05 23:56), Tom Lane wrote:
> Robert Haas writes:
>> Checking the functions of the operators is the right thing to do, but
>> assuming that internal = safe does not work. For example, pushing
>> down arithmetic operators allows you to probe for any given value in a
>> hidden row by testin
On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane wrote:
> Personally I think this is a dead end that we shouldn't be wasting
> any more time on.
But you haven't proposed a reasonable alternative.
As far as I can see, there are only two ways to go here.
Option #1: Remove all mention from the documentat
Robert Haas writes:
> Checking the functions of the operators is the right thing to do, but
> assuming that internal = safe does not work. For example, pushing
> down arithmetic operators allows you to probe for any given value in a
> hidden row by testing whether 1 / (x - constant) throws a divi
On Tue, Oct 5, 2010 at 10:27 AM, KaiGai Kohei wrote:
> (2010/10/05 23:16), Robert Haas wrote:
>>
>> 2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL
language
here. But we also have SQL functions by default. Some of them are just a
w
(2010/10/05 23:16), Robert Haas wrote:
2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL language
here. But we also have SQL functions by default. Some of them are just a
wrapper to internal functions. I'm not sure the checking of INTERNAL language
is the
2010/10/5 KaiGai Kohei :
>> The term "built-in functions" means functions written in INTERNAL language
>> here. But we also have SQL functions by default. Some of them are just a
>> wrapper to internal functions. I'm not sure the checking of INTERNAL language
>> is the best way for the purpose. Did
(2010/10/05 18:01), Itagaki Takahiro wrote:
> 2010/9/6 KaiGai Kohei:
>> The attached patch tackles both of the above two points, and allows to
>> control this deoptimization when CREATE SECURITY VIEW is used.
>
> I'll send a review for the patch.
>
Thanks for your reviewing.
> Contents& Purpose
2010/9/6 KaiGai Kohei :
> The attached patch tackles both of the above two points, and allows to
> control this deoptimization when CREATE SECURITY VIEW is used.
I'll send a review for the patch.
Contents & Purpose
==
The patch adds a new SECURITY option for VIEWs. Views defined w
(2010/09/02 13:30), KaiGai Kohei wrote:
> (2010/09/02 12:38), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> (2010/09/02 11:57), Robert Haas wrote:
2010/9/1 KaiGai Kohei:
> Right now, it stands on a strict assumption that considers operators
> implemented with built-in functions are
(2010/09/02 12:38), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> (2010/09/02 11:57), Robert Haas wrote:
>>> 2010/9/1 KaiGai Kohei:
Right now, it stands on a strict assumption that considers operators
implemented with built-in functions are safe; it does not have no
possibility to l
2010/9/1 KaiGai Kohei :
> (2010/09/02 11:57), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> Right now, it stands on a strict assumption that considers operators
>>> implemented with built-in functions are safe; it does not have no
>>> possibility to leak supplied arguments anywhere.
>>>
>>> Plea
(2010/09/02 11:57), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> Right now, it stands on a strict assumption that considers operators
>> implemented with built-in functions are safe; it does not have no
>> possibility to leak supplied arguments anywhere.
>>
>> Please note that this patch does not
2010/9/1 KaiGai Kohei :
> Right now, it stands on a strict assumption that considers operators
> implemented with built-in functions are safe; it does not have no
> possibility to leak supplied arguments anywhere.
>
> Please note that this patch does not case about a case when
> a function inside a
(2010/07/21 19:35), KaiGai Kohei wrote:
> (2010/07/21 19:26), Robert Haas wrote:
>> 2010/7/21 KaiGai Kohei:
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.
>>> I also think i
(2010/07/21 19:26), Robert Haas wrote:
2010/7/21 KaiGai Kohei:
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.
I also think it is a worthful idea to try as a proof-of-concept.
Yeah. So,
2010/7/21 KaiGai Kohei :
>> 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.
>>
> I also think it is a worthful idea to try as a proof-of-concept.
Yeah. So, should we mark this patch as R
2010/7/21 KaiGai Kohei :
> (2010/07/20 2:13), Heikki Linnakangas wrote:
>> 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
(2010/07/20 2:19), Heikki Linnakangas wrote:
> On 19/07/10 20:08, Robert Haas wrote:
>> 2010/7/8 KaiGai Kohei:
>>> (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 SECUR
(2010/07/20 2:13), Heikki Linnakangas wrote:
> 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 function
On Mon, Jul 19, 2010 at 1:19 PM, Heikki Linnakangas
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
--
Rob
On 19/07/10 20:08, Robert Haas wrote:
2010/7/8 KaiGai Kohei:
(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 disclo
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
2010/7/8 KaiGai Kohei :
> (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 pu
(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, p
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 sufficie
78 matches
Mail list logo
