(2010/06/08 11:15), Robert Haas wrote:
> 2010/6/7 KaiGai Kohei:
>> Our headache is on functions categorized to middle-threat. It enables to
>> leak the given arguments using error messages. Here are several ideas,
>> but they have good and bad points.
>
> I think we are altogether off in the weeds
(2010/06/08 11:28), Stephen Frost wrote:
> For the sake of clarity..
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> OK, it was too implementation-specific.
>
> No, that wasn't the problem. There isn't an actual implementation yet
> for it to be too-specific on. The problem is that proposin
For the sake of clarity..
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> OK, it was too implementation-specific.
No, that wasn't the problem. There isn't an actual implementation yet
for it to be too-specific on. The problem is that proposing a change to
the catalog without figuring out what it
(2010/06/08 11:15), Robert Haas wrote:
> 2010/6/7 KaiGai Kohei:
>> Our headache is on functions categorized to middle-threat. It enables to
>> leak the given arguments using error messages. Here are several ideas,
>> but they have good and bad points.
>
> I think we are altogether off in the weeds
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/7 KaiGai Kohei :
> > Our headache is on functions categorized to middle-threat. It enables to
> > leak the given arguments using error messages. Here are several ideas,
> > but they have good and bad points.
>
> I think we are altogether off in
2010/6/7 KaiGai Kohei :
> Our headache is on functions categorized to middle-threat. It enables to
> leak the given arguments using error messages. Here are several ideas,
> but they have good and bad points.
I think we are altogether off in the weeds here. We ought to start
with an implementatio
(2010/06/08 10:17), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Perhaps, pg_proc takes a new flag to represent it.
>
> Without an actual well-formed approach for dealing with this which
> requires it, it's far too soon to be asking for changes in the catalog
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Perhaps, pg_proc takes a new flag to represent it.
Without an actual well-formed approach for dealing with this which
requires it, it's far too soon to be asking for changes in the catalog.
Please stop suggesting individual maybe-this-would-h
(2010/06/08 9:46), Tom Lane wrote:
> KaiGai Kohei writes:
>> In this case, is it unnecessary to expose the given argument in
>> the error message (from security perspective), isn't it?
>
> Yes, if all you care about is security and not usability, that looks
> like a great solution. We're *not* d
On Tue, Jun 8, 2010 at 1:46 AM, Tom Lane wrote:
> KaiGai Kohei writes:
>> In this case, is it unnecessary to expose the given argument in
>> the error message (from security perspective), isn't it?
>
> Yes, if all you care about is security and not usability, that looks
> like a great solution.
(2010/06/08 9:23), KaiGai Kohei wrote:
> (2010/06/07 21:56), Stephen Frost wrote:
>> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>>> WHERE should do it:
>>>
>>> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
>>> password::integer = 1234;
>>> ERROR: invalid input s
KaiGai Kohei writes:
> In this case, is it unnecessary to expose the given argument in
> the error message (from security perspective), isn't it?
Yes, if all you care about is security and not usability, that looks
like a great solution. We're *not* doing it.
regards, to
(2010/06/07 21:56), Stephen Frost wrote:
> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>> WHERE should do it:
>>
>> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
>> password::integer = 1234;
>> ERROR: invalid input syntax for integer: "neighborssecretpassword"
>>
(2010/06/07 20:53), Heikki Linnakangas wrote:
> On 07/06/10 14:06, Stephen Frost wrote:
>> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>>> The big difference is what information can be obtained, not how fast it
>>> can be obtained.
>>
>> Actually, I disagree. Time required to
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> WHERE should do it:
>
> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
> password::integer = 1234;
> ERROR: invalid input syntax for integer: "neighborssecretpassword"
>
> Assuming that username = 'neighbor' is evalu
On 07/06/10 14:06, Stephen Frost wrote:
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
The big difference is what information can be obtained, not how fast it
can be obtained.
Actually, I disagree. Time required to acquire the data does matter.
Depends on the magnitude, o
Heikki,
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> The big difference is what information can be obtained, not how fast it
> can be obtained.
Actually, I disagree. Time required to acquire the data does matter.
> Imagine a table that holds username/passwords for users.
On 07/06/10 10:30, KaiGai Kohei wrote:
> (2010/06/07 15:48), Heikki Linnakangas wrote:
>> There's many side channels like exposing row counts in EXPLAIN and
>> statistics and timing attacks, that are not as critical, because they
>> don't let expose all data, and the attacker can't accurately choos
(2010/06/07 15:48), Heikki Linnakangas wrote:
> On 07/06/10 06:06, Stephen Frost wrote:
>> Also, perhaps I'm not being paranoid enough, but all this concern over
>> error cases really doesn't really worry me that much. The amount of
>> data one could acquire that way is pretty limited.
>
> It's no
On 07/06/10 06:06, Stephen Frost wrote:
Also, perhaps I'm not being paranoid enough, but all this concern over
error cases really doesn't really worry me that much. The amount of
data one could acquire that way is pretty limited.
It's not limited. It allows you to read all contents of the unde
(2010/06/07 12:06), Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Another idea I had was... would it be safe to trust functions defined
>> by the same user who owns the view? If he's granted access to the
>> view and the function to some other user, presumably he doesn't m
(2010/06/07 10:38), Robert Haas wrote:
> On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 04/06/10 22:33, Tom Lane wrote:
A counterexample: suppose we had a form of type "text" that carried a
collation specifier internally, and the comparison routine
* Robert Haas (robertmh...@gmail.com) wrote:
> Another idea I had was... would it be safe to trust functions defined
> by the same user who owns the view? If he's granted access to the
> view and the function to some other user, presumably he doesn't mind
> them being used together? Or is that to
On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 04/06/10 22:33, Tom Lane wrote:
>>> A counterexample: suppose we had a form of type "text" that carried a
>>> collation specifier internally, and the comparison routine threw an
>>> error if asked to compare values
Heikki Linnakangas writes:
> On 04/06/10 22:33, Tom Lane wrote:
>> A counterexample: suppose we had a form of type "text" that carried a
>> collation specifier internally, and the comparison routine threw an
>> error if asked to compare values with incompatible specifiers. An index
>> built on a
On 04/06/10 22:33, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/06/10 17:33, Tom Lane wrote:
Maybe the entire idea is unworkable. I certainly don't find any comfort
in your proposal in the above-referenced message to trust index
operators; where is it written that those don't throw errors
Heikki Linnakangas writes:
> On 04/06/10 17:33, Tom Lane wrote:
>> Maybe the entire idea is unworkable. I certainly don't find any comfort
>> in your proposal in the above-referenced message to trust index
>> operators; where is it written that those don't throw errors?
> Let's consider b-tree o
On Fri, Jun 4, 2010 at 1:46 PM, Heikki Linnakangas
wrote:
> On 04/06/10 17:33, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> On 04/06/10 07:57, Tom Lane wrote:
The proposal some time back in this thread was to trust all built-in
functions and no others.
>>
>>> I thought
On 04/06/10 17:33, Tom Lane wrote:
Heikki Linnakangas writes:
On 04/06/10 07:57, Tom Lane wrote:
The proposal some time back in this thread was to trust all built-in
functions and no others.
I thought I debunked that idea already
(http://archives.postgresql.org/pgsql-hackers/2009-10/msg0142
On Fri, 2010-06-04 at 10:33 -0400, Tom Lane wrote:
> Hmm ... that's a mighty interesting example, because it shows that any
> well-meaning change in error handling might render seemingly-unrelated
> functions "unsafe". And we're certainly not going to make error
> messages stop showing relevant in
Heikki Linnakangas writes:
> On 04/06/10 07:57, Tom Lane wrote:
>> The proposal some time back in this thread was to trust all built-in
>> functions and no others.
> I thought I debunked that idea already
> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not
> all built-in
On 04/06/10 07:57, Tom Lane wrote:
KaiGai Kohei writes:
(2010/06/04 11:55), Robert Haas wrote:
A (very) important part of this problem is determining which quals are
safe to push down.
At least, I don't have an idea to distinguish trusted functions from
others without any additional hints, b
(2010/06/04 18:26), Dimitri Fontaine wrote:
Tom Lane writes:
The proposal some time back in this thread was to trust all built-in
functions and no others. That's a bit simplistic, no doubt, but it
seems to me to largely solve the performance problem and to do so with
minimal effort. When and
Tom Lane writes:
> The proposal some time back in this thread was to trust all built-in
> functions and no others. That's a bit simplistic, no doubt, but it
> seems to me to largely solve the performance problem and to do so with
> minimal effort. When and if you get to a solution that's committ
(2010/06/04 13:57), Tom Lane wrote:
> KaiGai Kohei writes:
>> (2010/06/04 11:55), Robert Haas wrote:
>>> A (very) important part of this problem is determining which quals are
>>> safe to push down.
>>>
>> At least, I don't have an idea to distinguish trusted functions from
>> others without any a
KaiGai Kohei writes:
> (2010/06/04 11:55), Robert Haas wrote:
>> A (very) important part of this problem is determining which quals are
>> safe to push down.
>>
> At least, I don't have an idea to distinguish trusted functions from
> others without any additional hints, because we support variabl
(2010/06/04 11:55), Robert Haas wrote:
> On Thu, Jun 3, 2010 at 1:23 PM, Marc Munro wrote:
>> On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
>> wrote:
>>> [ . . . ]
>>>
>>> In my current idea, when a qual-node that contains FuncExpr tries to
>>> reference a part of relations
I fixed up the subject.
(2010/06/04 2:23), Marc Munro wrote:
> On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
> wrote:
>> [ . . . ]
>>
>> In my current idea, when a qual-node that contains FuncExpr tries to
>> reference a part of relations within a security view, its referen
The attached patch is a proof of concept.
It tries to fix the problem of leaky VIEWs for RLS.
* The scenario of leaky VIEWs for RLS
-
When a view contains any table joins and user gives a function that
takes arguments depending on only one-side table of the join
39 matches
Mail list logo
