On Sun, Apr 25, 2021 at 02:40:54PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch
> > > > > > wrote:
> > > > > >> Hence, I do find it reasonable to let
Stephen Frost writes:
> * Andrey Borodin (x4...@yandex-team.ru) wrote:
>> Customer was restoring pg_dump of on-premise ERP known as 1C (something like
>> TurboTax) with this add-on [0]
> Erm, it's very clearly not leakproof and will happily return information
> about the value passed in during s
Greetings,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> > > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient
> > > > >> for
> > > > >> setting LEAKPR
Greetings,
* Andrey Borodin (x4...@yandex-team.ru) wrote:
> > 20 апр. 2021 г., в 02:38, Stephen Frost написал(а):
> > Here's what I'd ask Andrey- what's the actual use-case here? Are these
> > cases where users are actually adding new functions which they believe
> > are leakproof where those fu
> 20 апр. 2021 г., в 02:38, Stephen Frost написал(а):
>
> Here's what I'd ask Andrey- what's the actual use-case here? Are these
> cases where users are actually adding new functions which they believe
> are leakproof where those functions don't require superuser already to
> be created? Cle
On Mon, Apr 19, 2021 at 05:38:43PM -0400, Stephen Frost wrote:
> > > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> > > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient
> > > >> for
> > > >> setting LEAKPROOF.
> I'm not really sure that attaching it to pg_read_all_d
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Apr 19, 2021 at 4:32 PM Tom Lane wrote:
> > Robert Haas writes:
> > > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> > >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
> > >> setting LEAKPROOF. I
On Mon, Apr 19, 2021 at 4:32 PM Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> >> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
> >> setting LEAKPROOF. I would not consult datdba, because datdba currently
> >> has
> >> n
Robert Haas writes:
> On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
>> Hence, I do find it reasonable to let pg_read_all_data be sufficient for
>> setting LEAKPROOF. I would not consult datdba, because datdba currently has
>> no special read abilities. It feels too weird to let BYPASSRLS st
On Fri, Apr 16, 2021 at 3:57 AM Noah Misch wrote:
> On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> > On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > > I doubt that falsely labeling a function LEAKPROOF can get you more
> > > than the ability to read data you're not supposed to
On Mon, Apr 12, 2021 at 02:35:27PM -0700, Andres Freund wrote:
> On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> > I doubt that falsely labeling a function LEAKPROOF can get you more
> > than the ability to read data you're not supposed to be able to read
> > ... but that ability is then available
Hi,
On 2021-04-12 17:14:20 -0400, Tom Lane wrote:
> I doubt that falsely labeling a function LEAKPROOF can get you more
> than the ability to read data you're not supposed to be able to read
> ... but that ability is then available to all users, or at least all
> users who can execute the function
Andres Freund writes:
> On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote:
>> Do I risk having some extra superusers in my installation if I allow
>> everyone to create LEAKPROOF functions?
> I think that depends on what you define "superuser" to exactly
> be. Defining it as "has a path to execu
> 13 апр. 2021 г., в 00:01, Andres Freund написал(а):
>
> Hi,
>
> On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote:
>> Do I risk having some extra superusers in my installation if I allow
>> everyone to create LEAKPROOF functions?
>
> I think that depends on what you define "superuser" to
Hi,
On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote:
> Do I risk having some extra superusers in my installation if I allow
> everyone to create LEAKPROOF functions?
I think that depends on what you define "superuser" to exactly
be. Defining it as "has a path to executing arbitrary native code
Thanks, Tomas!
> 12 апр. 2021 г., в 23:42, Tomas Vondra
> написал(а):
>
> I guess for the cloud services it's not an issue - they're mostly
> concerned about manageability and restricting access to the OS.
In fact, we would happily give a client access to an OS too. It's a client's VM
after al
Hi,
On 2021-04-12 22:42:03 +0200, Tomas Vondra wrote:
> It's unfortunate that we tie the this capability to being superuser,
> so maybe the right solution would be to introduce a separate role with
> this privilege?
Perhaps DB owner + BYPASSRLS would be enough?
Greetings,
Andres Freund
Hi,
On 2021-04-12 16:37:01 -0400, Tom Lane wrote:
> Andrey Borodin writes:
> > Currently only superuser is allowed to create LEAKPROOF functions
> > because leakproof functions can see tuples which have not yet been
> > filtered out by security barrier views or row level security
> > policies.
>
Thanks for so quick response, Tom!
> 12 апр. 2021 г., в 23:37, Tom Lane написал(а):
>
>> But managed cloud services typically do not provide superuser roles.
>
> This is not a good argument for relaxing superuser requirements.
Ok, let's put aside question about relaxing requirements in upstream
On 4/12/21 10:37 PM, Tom Lane wrote:
> Andrey Borodin writes:
>> Currently only superuser is allowed to create LEAKPROOF functions
>> because leakproof functions can see tuples which have not yet been
>> filtered out by security barrier views or row level security
>> policies.
>
> Yeah.
>
>> B
Andrey Borodin writes:
> Currently only superuser is allowed to create LEAKPROOF functions because
> leakproof functions can see tuples which have not yet been filtered out by
> security barrier views or row level security policies.
Yeah.
> But managed cloud services typically do not provide s
21 matches
Mail list logo
