Re: "set role" semantics

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
Cc: pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: "set role" semantics
Date: 2022-11-09 19:29:33
Message-ID: CAKFQuwYxmv=GX_zAMNDO0U409m_kcD83T-TkyOMex_cRF+bXYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Nov 8, 2022 at 5:16 PM Bryn Llewellyn <bryn(at)yugabyte(dot)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 that, as far as I've taken this test, "d2$mgr" is entirely
> impotent when the "current_database()" is "d1". Is this, maybe, just as
> good as it gets. I suppose I can live with what seems to me to be very odd
> as long as no harm can come of it.
>

Yes. In short, you can prevent a person from connecting to specific
databases by ensuring the credentials they hold only resolve successfully
on those specific databases. Both via connect privilege and pg_hba.conf
can this be done. But that person, while connected to any databases, can
assume any roles the user name of the credentials they used are a member
of. Whether that is actually useful or not depends upon grants. But in no
case can you prevent them from, say, examining the database catalog tables,
or executing at least some limited SQL.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2022-11-09 20:31:47 Re: "set role" semantics
Previous Message Adrian Klaver 2022-11-09 19:27:23 Re: "set role" semantics