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 origi
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
considerati
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 requirem
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 pe
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 so
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 thin
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 of
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 n
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 sh
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 g
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 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 t
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
ex
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
> >> unusable.
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
>> me
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 questio
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 self-c
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 I'
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
message
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,
> not
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. S
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
https://www.postgresql.org/message-id/flat
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 tr
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 monitoring
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 south
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.
The
28 matches
Mail list logo
