From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au> |
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:50:12 |
Message-ID: | 87E0DAE2-248C-4F47-B333-436D515FD36D@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Nov 7, 2022, at 17:43, Jan Bilek <jan(dot)bilek(at)eftlab(dot)com(dot)au> wrote:
>
> 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.
Well... don't do that. :) The problem is analogous to having root log into a Linux box and run application commands. It works, but it opens a security hole, as you've discovered.
> Yes, agreed. Any ideas?
In this particular case (creating an untrusted PL and functions therein), you'll need to use a PostgreSQL superuser. This is a separate operation from routine application use, though. (I'll note that having functions in an untrusted PL in a PCI-sensitive system is not a great idea, as you'll need to audit them very closely to make sure that they can't do anything untoward outside the role system.)
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-11-08 01:51:02 | Re: PCI:SSF - Safe SQL Query & operators filter |
Previous Message | Jan Bilek | 2022-11-08 01:43:02 | Re: PCI:SSF - Safe SQL Query & operators filter |