From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: connect permission based on database name |
Date: | 2022-05-25 14:44:18 |
Message-ID: | CAKFQuwbtH3tGhz5PNUWL6HQzhmMG_+qLpbaE3WtuSxSorMh1Pg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wednesday, May 25, 2022, Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
> On 5/25/22 08:20, Tom Lane wrote:
>
> Rob Sargent <robjsargent(at)gmail(dot)com> <robjsargent(at)gmail(dot)com> writes:
>
> Just wondering if I've bumped into some security issue.
> I'm somewhat surprised that "grant connect to database <dbname> to
> <role>" appears to be stored "by name"?
>
> I think you are forgetting that databases have a default GRANT CONNECT
> TO PUBLIC. You need to revoke that before other grants/revokes will
> have any functional effect.
>
> regards, tom lane
>
> And then the search path is "just a string"?
>
>
>
Search_path isn’t a security component and accepts, but ignores, unknown
names. So yes, it is just a string.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2022-05-25 14:45:26 | Re: connect permission based on database name |
Previous Message | Rob Sargent | 2022-05-25 14:38:31 | Re: connect permission based on database name |