Re: "set role" semantics

> adrian.kla...@aklaver.com wrote: > >> b...@yugabyte.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

Re: "set role" semantics

On 11/9/22 15:23, Bryn Llewellyn wrote: adrian.kla...@aklaver.com wrote: b...@yugabyte.com wrote: Connecting to database and the role that is in play inside a session are two different things. Making them the same would make things [security define vs "security invoker"] go sideways. I s

Re: "set role" semantics

adrian.kla...@aklaver.com wrote: > >> b...@yugabyte.com wrote: > > Connecting to database and the role that is in play inside a session are two > different things. Making them the same would make things [security define vs > "security invoker"] go sideways. I said nothing to suggest that the r

Re: "set role" semantics

On 11/9/22 12:31, Bryn Llewellyn wrote: Thanks. If nobody thinks that ending up as I showed is possible brings any kind of risk, then I’m happy to accept that. More generally, I’m a huge fan of the principle of least privilege, and (as far as it concerns what I asked about in this thread), it

Re: "set role" semantics

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> Is there anything that can be done to limit the scope of the ability to end >> up in a database like I'd thought would be possible? (A little test showed >> me that "set role" doesn't fire an event trigger.) >> >> I do see

Re: "set role" semantics

On Tue, Nov 8, 2022 at 5:16 PM Bryn Llewellyn wrote: > > Is there anything that can be done to limit the scope of the ability to > end up in a database like I'd thought would be possible? (A little test > showed me that "set role" doesn't fire an event trigger.) > > I do see that, as far as I've

Re: "set role" semantics

On 11/9/22 10:55 AM, Bryn Llewellyn wrote: adrian.kla...@aklaver.com wrote: Revoking PUBLIC has been explained before to you (Bryn Llewellyn). A quick search: https://www.postgresql.org/message-id/2176817.1644613...@sss.pgh.pa.us

Re: "set role" semantics

On Wed, Nov 9, 2022 at 11:55 AM Bryn Llewellyn wrote: > > Here's an extract from the script that I copied in my first email: > > > > > > > *create database d1;revoke all on database d1 from public;create database > d2;revoke all on database d2 from public;* > > Didn't I do exactly what you both s

Re: "set role" semantics

On 11/9/22 10:55 AM, Bryn Llewellyn wrote: adrian.kla...@aklaver.com wrote: Revoking PUBLIC has been explained before to you (Bryn Llewellyn). A quick search: https://www.postgresql.org/message-id/2176817.1644613...@sss.pgh.pa.us

Re: "set role" semantics

Hi, Le mer. 9 nov. 2022, 19:55, Bryn Llewellyn a écrit : > adrian.kla...@aklaver.com wrote: > > david.g.johns...@gmail.com wrote: > > b...@yugabyte.com wrote: > > Notice that I didn't grant "connect" on either of the databases, "d1" or > "d2", to any of the roles, "clstr$mgr, "d1$mgr", or "d2$mg

Re: "set role" semantics

> adrian.kla...@aklaver.com wrote: > >> david.g.johns...@gmail.com wrote: >> >>> b...@yugabyte.com wrote: >>> >>> Notice that I didn't grant "connect" on either of the databases, "d1" or >>> "d2", to any of the roles, "clstr$mgr, "d1$mgr", or "d2$mgr". >> >> You didn't have to since PUBLIC get

Re: "set role" semantics

On 11/8/22 16:24, David G. Johnston wrote: On Tue, Nov 8, 2022, 17:16 Bryn Llewellyn > wrote: Notice that I didn't grant "connect" on either of the databases, "d1" or "d2", to any of the roles, "clstr$mgr, "d1$mgr", or "d2$mgr". You didn't have to since PUBLI

Re: "set role" semantics

On Tue, Nov 8, 2022, 17:16 Bryn Llewellyn wrote: > > Notice that I didn't grant "connect" on either of the databases, "d1" or > "d2", to any of the roles, "clstr$mgr, "d1$mgr", or "d2$mgr". > You didn't have to since PUBLIC gets that privilege and you didn't revoke it. https://www.postgresql.or

"set role" semantics

I created a little test to demonstrate to myself how “set role” works. I ran it in a freshly-created PG 11.17 cluster on Ubuntu, installed and configured like I’ve recently discussed on this list. I copied my "pg-init.sh" script at the end. I then did this test, after starting like this (as the