(2010/06/08 11:15), Robert Haas wrote:
2010/6/7 KaiGai Koheikai...@ak.jp.nec.com:
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
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
(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 not
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 choose what
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 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,
* 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 evaluated
(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 acquire the
(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
Assuming
KaiGai Kohei kai...@ak.jp.nec.com 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.
(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 syntax for
On Tue, Jun 8, 2010 at 1:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com 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
(2010/06/08 9:46), Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com 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.
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
(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.
2010/6/7 KaiGai Kohei kai...@ak.jp.nec.com:
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
* Robert Haas (robertmh...@gmail.com) wrote:
2010/6/7 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/06/08 11:15), Robert Haas wrote:
2010/6/7 KaiGai Koheikai...@ak.jp.nec.com:
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
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
(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 proposing a
On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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 too
(2010/06/07 10:38), Robert Haas wrote:
On Fri, Jun 4, 2010 at 4:12 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
(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 mind
Tom Lane t...@sss.pgh.pa.us 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
(2010/06/04 18:26), Dimitri Fontaine wrote:
Tom Lanet...@sss.pgh.pa.us 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
On 04/06/10 07:57, Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
On 04/06/10 17:33, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
On Fri, Jun 4, 2010 at 1:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 04/06/10 17:33, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 04/06/10 07:57, Tom Lane wrote:
The proposal some time back in this thread was to trust all
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 04/06/10 22:33, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
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 referencing
(2010/06/04 11:55), Robert Haas wrote:
On Thu, Jun 3, 2010 at 1:23 PM, Marc Munrom...@bloodnok.com 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
KaiGai Kohei kai...@ak.jp.nec.com 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
(2010/06/04 13:57), Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com 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
39 matches
Mail list logo
