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
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
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
> 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?
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
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
> >>
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
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
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
> 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
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
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
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.
>
>>
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
Hi hackers!
This thread continues discussion of allowing something to non-superuser, AFAIK
previous was [0].
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
22 matches
Mail list logo
