Re: "set role" semantics

From: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: "set role" semantics
Date: 2022-11-10 06:13:40
Message-ID: 095E6036-23F6-42FD-B1C6-F5A56B69B8ED@yugabyte.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> adrian(dot)klaver(at)aklaver(dot)com wrote:
>
>> bryn(at)yugabyte(dot)com wrote:
>>
>> Anyway, all this is moot (except in that thinking about it helps me to enrich my mental model) because the privilege notions here will never change.
>
> So, I want it but not really.

I’d rather say “I’d very much prefer it if I had it. But, because I don’t, I will have to write a comment essay to explain what tests might show and why these outcomes that might seem worrisome at first sight can be seen, after an exercise of reasoning, to be harmless. I’m not a fan of that kind of essay writing. But I’ll do it if I have to.

>> Yes I have actually done this. But rigorous testing remains to be done... The point (conforming to the principle of least privilege) is that sessions that connect as "client" must not be allowed to do arbitrary SQL. Rather, they should be able to do only what has been explicitly "white-listed" in by the encapsulation provided by the API-defining subprograms.
>
> All right that I get.

Good. I’m relieved that you haven’t (yet) spotted a flaw in my scheme.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ian Lawrence Barwick 2022-11-10 06:25:12 Re: List user databases
Previous Message Julien Rouhaud 2022-11-10 05:22:01 Re: List user databases