From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
---|---|
To: | David Gauthier <davegauthierpg(at)gmail(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Securing records using linux grou permissions |
Date: | 2019-10-16 06:26:41 |
Message-ID: | CAKoxK+6Dg_K9yQ4x0Fk_JdVD5N3R9tLm6XBHSfp4=q-EWgpPUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Oct 15, 2019 at 6:07 PM David Gauthier <davegauthierpg(at)gmail(dot)com> wrote:
> Users are going to be working with data through perl/DBI scripts which currently connect using a generic role with hardcoded password in the connect string. Access will be select/insert/update/delete We need to tighten up security as described above.
I would apply row level security, as already pointed out.
Then, in my Perl scripts, I will force a SET ROLE depending on the
operating system group/user. In such case, you can have still a
"generic" user to use as connection/login, then change the set of
permissions on the fly as connected. Of course, row level security
must be applied against current_role and not session_user.
I would not say this is a robust approach, but can do what you want
(assuming you don't have to change thousands of Perl scripts).
Hope it helps.
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Durgamahesh Manne | 2019-10-16 09:27:00 | Re: Regarding db dump with Fc taking very long time to completion |
Previous Message | imai.yoshikazu@fujitsu.com | 2019-10-16 06:25:33 | RE: v12 and pg_restore -f- |