From: | Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PCI:SSF - Safe SQL Query & operators filter |
Date: | 2022-11-08 01:43:02 |
Message-ID: | 33a762ed-a045-c1e5-a042-cd4903f7de4b@eftlab.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/8/22 11:29, Christophe Pettus wrote:
>
>> On Nov 7, 2022, at 17:24, Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au> wrote:
>> Would there be any way to go around this?
> The typical configuration is to not permit the PostgreSQL superuser to log in remotely. The database can be managed by a different, non-superuser role, including schema migrations.
Well, superuser (our App) is already logged in and as it is designed
very much as an "appliance" it simply does that job - manages its
database. There might be a way to explore whether we can use internally
another (limited) user just for reporting queries on a different
connection session. But I am getting (security related) headaches just
thinking about it.
>
>> CREATE OR REPLACE LANGUAGE plpython3u;
>> HINT: Must be superuser to create this extension.
> The reason only a superuser can create this extension is the "u" at the end of the name: It is an untrusted PL that can bypass PostgreSQL's role system. If anyone could create functions in it, anyone could bypass roles.
Yes, agreed. Any ideas?
--
Jan Bilek - CTO at EFTlab Pty Ltd.
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2022-11-08 01:50:12 | Re: PCI:SSF - Safe SQL Query & operators filter |
Previous Message | Christophe Pettus | 2022-11-08 01:29:44 | Re: PCI:SSF - Safe SQL Query & operators filter |