Re: PCI:SSF - Safe SQL Query & operators filter

Поиск
Список
Период
Сортировка
От Jan Bilek
Тема Re: PCI:SSF - Safe SQL Query & operators filter
Дата
Msg-id 33a762ed-a045-c1e5-a042-cd4903f7de4b@eftlab.com.au
обсуждение исходный текст
Ответ на Re: PCI:SSF - Safe SQL Query & operators filter  (Christophe Pettus <xof@thebuild.com>)
Ответы Re: PCI:SSF - Safe SQL Query & operators filter  (Christophe Pettus <xof@thebuild.com>)
Список pgsql-general
On 11/8/22 11:29, Christophe Pettus wrote:
>
>> On Nov 7, 2022, at 17:24, Jan Bilek <jan.bilek@eftlab.com.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
bya 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
canbypass 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.


В списке pgsql-general по дате отправления:

Предыдущее
От: Christophe Pettus
Дата:
Сообщение: Re: PCI:SSF - Safe SQL Query & operators filter
Следующее
От: Christophe Pettus
Дата:
Сообщение: Re: PCI:SSF - Safe SQL Query & operators filter