On 2019-03-18 20:08, Peter Eisentraut wrote:
> I agree that it would be useful to document and discuss better which
> built-in operators are leak-proof and which are not. But I don't think
> the CREATE POLICY reference page is the place to do it. Note that the
> leak-proofness mechanism was
Hi Pierre,
On 3/18/19 8:13 PM, Joe Conway wrote:
I have no idea what the other entry is all about as I have not had the
time to look.
There doesn't seem to be consensus on your patch, either -- I'm planning
to mark it rejected at the end of the CF unless you have a new patch for
On 3/18/19 3:52 PM, Peter Eisentraut wrote:
> On 2019-02-28 00:03, Joe Conway wrote:
>> What if we provided an option to redact all client messages (leaving
>> logged messages as-is). Separately we could provide a GUC to force all
>> functions to be resolved as leakproof. Depending on your
On 2019-02-28 00:03, Joe Conway wrote:
> What if we provided an option to redact all client messages (leaving
> logged messages as-is). Separately we could provide a GUC to force all
> functions to be resolved as leakproof. Depending on your requirements,
> having both options turned on could be
On 2019-02-21 15:56, Pierre Ducroquet wrote:
> I undestand these decisions, but it makes RLS quite fragile, with numerous un-
> documented side-effects. In order to save difficulties from future users, I
> wrote this patch to the documentation, listing the biggest restrictions I hit
> with RLS
On 2/28/19 12:28 PM, Robert Haas wrote:
> Mmmph. If your customers always have a non-production instance where
> problems from production can be easily reproduced, your customers are
> not much like our customers.
Well I certainly did not mean to imply that this is always the case ;-)
But I
On Thu, Feb 28, 2019 at 12:05 PM Joe Conway wrote:
> I think that would affect the server logs too, no? Worth thinking about
> though...
Yeah, I suppose so, although there might be a way to work around that.
> Also manually marking all functions leakproof is far less convenient
> than turning
On 2/28/19 11:50 AM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 11:44 AM Joe Conway wrote:
>> No, and Tom stated as much too, but life is all about tradeoffs. Some
>> people will find this an acceptable compromise. For those that don't
>> they don't have to use it. IMHO we tend toward too much
On Thu, Feb 28, 2019 at 11:44 AM Joe Conway wrote:
> No, and Tom stated as much too, but life is all about tradeoffs. Some
> people will find this an acceptable compromise. For those that don't
> they don't have to use it. IMHO we tend toward too much nannyism too often.
Well, I agree with that,
On 2/28/19 11:37 AM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote:
>> > Although, and Joe may hate me for saying this, I think only the
>> > non-constants should be redacted to keep some level of usability for
>> > regular SQL errors. Maybe system errors like the above
On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote:
> > Although, and Joe may hate me for saying this, I think only the
> > non-constants should be redacted to keep some level of usability for
> > regular SQL errors. Maybe system errors like the above should be
> > removed from client messages in
On Thu, Feb 28, 2019 at 11:14 AM Joe Conway wrote:
>
> > Although, and Joe may hate me for saying this, I think only the
> > non-constants should be redacted to keep some level of usability for
> > regular SQL errors. Maybe system errors like the above should be
> > removed from client messages
On 2/28/19 11:03 AM, Joshua Brindle wrote:
> On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote:
>>
>> Joshua Brindle writes:
>> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
>> >> So... you're just going to replace ALL error messages of any kind with
>> >> "ERROR: missing error text" when
On 2/28/19 11:03 AM, Joshua Brindle wrote:
> How is leakproof defined WRT Postgres? Generally speaking a 1 bit
>From the CREATE FUNCTION reference page:
LEAKPROOF indicates that the function has no side effects. It reveals no
information about its arguments other than by its return value. For
On Thu, Feb 28, 2019 at 10:49 AM Tom Lane wrote:
>
> Joshua Brindle writes:
> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
> >> So... you're just going to replace ALL error messages of any kind with
> >> "ERROR: missing error text" when this option is enabled? That sounds
> >>
Joshua Brindle writes:
> On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
>> So... you're just going to replace ALL error messages of any kind with
>> "ERROR: missing error text" when this option is enabled? That sounds
>> unusable. I mean if I'm reading it right this would get not only
>>
On Thu, Feb 28, 2019 at 9:12 AM Robert Haas wrote:
Hi, Robert, it has been a while :)
>
> So... you're just going to replace ALL error messages of any kind with
> "ERROR: missing error text" when this option is enabled? That sounds
> unusable. I mean if I'm reading it right this would get not
On 2/28/19 9:52 AM, Dean Rasheed wrote:
> Does self-censoring mean that they might still throw an error for some
> inputs, but that error won't reveal any information about the input
> values? That's not entirely consistent with my understanding of the
> definition of leakproof
That's the
On Thu, 28 Feb 2019 at 14:13, Robert Haas wrote:
> A wild idea might be to let
> proleakproof take on three values: yes, no, and maybe. When 'maybe'
> functions are involved, we tell them whether or not the current query
> involves any security barriers, and if so they self-censor.
>
Does
On 2/28/19 9:12 AM, Robert Haas wrote:
> On Wed, Feb 27, 2019 at 6:03 PM Joe Conway wrote:
>> Patch for discussion attached.
>
> So... you're just going to replace ALL error messages of any kind with
> "ERROR: missing error text" when this option is enabled? That sounds
> unusable. I mean if
On Wed, Feb 27, 2019 at 6:03 PM Joe Conway wrote:
> Patch for discussion attached.
So... you're just going to replace ALL error messages of any kind with
"ERROR: missing error text" when this option is enabled? That sounds
unusable. I mean if I'm reading it right this would get not only
On 2/20/19 11:24 AM, Tom Lane wrote:
> Pierre Ducroquet writes:
>> For simple functions like enum_eq/enum_ne, marking them leakproof is an
>> obvious fix (patch attached to this email, including also textin/textout).
>
> This is not nearly as "obvious" as you think. See prior discussions,
>
On Wednesday, February 20, 2019 5:24:17 PM CET Tom Lane wrote:
> Pierre Ducroquet writes:
> > For simple functions like enum_eq/enum_ne, marking them leakproof is an
> > obvious fix (patch attached to this email, including also textin/textout).
>
> This is not nearly as "obvious" as you think.
Pierre Ducroquet writes:
> For simple functions like enum_eq/enum_ne, marking them leakproof is an
> obvious fix (patch attached to this email, including also textin/textout).
This is not nearly as "obvious" as you think. See prior discussions,
notably
On 2/19/19 6:43 PM, Laurenz Albe wrote:
> Pierre Ducroquet wrote:
>> if we had a 'RLS-enabled' context on functions, a way to make a lot of built-
>> in functions leakproof would simply be to prevent them from logging errors
>> containing values.
>>
>> For others, like arraycontains, it's much
On Wednesday, February 20, 2019 12:43:50 AM CET Laurenz Albe wrote:
> Pierre Ducroquet wrote:
> > In order to increase our security, we have started deploying row-level
> > security in order to add another safety net if any issue was to happen in
> > our applications.
> > After a careful
Pierre Ducroquet wrote:
> In order to increase our security, we have started deploying row-level
> security in order to add another safety net if any issue was to happen in our
> applications.
> After a careful monitoring of our databases, we found out that a lot of
> queries started to go
Hello
In order to increase our security, we have started deploying row-level
security in order to add another safety net if any issue was to happen in our
applications.
After a careful monitoring of our databases, we found out that a lot of
queries started to go south, going extremely slow.
28 matches
Mail list logo
