Re: Trusted versus untrusted Pl language
| От | Steven Pousty |
|---|---|
| Тема | Re: Trusted versus untrusted Pl language |
| Дата | |
| Msg-id | CAKmB1PEX3Wd2OiA4rFJUdMUY7L+xTvQVCEcfChVCUu2eSgUPXg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Trusted versus untrusted Pl language (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Trusted versus untrusted Pl language
|
| Список | pgsql-docs |
On Wed, Dec 23, 2020 at 4:49 PM Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Dec 23, 2020 at 07:38:16PM -0500, Tom Lane wrote:
> Steven Pousty <steve.pousty@gmail.com> writes:
> > 3. An example of how to make a pre-installed untrusted langue into a
> > trusted language
>
> Under what circumstances would that be a good idea?
>
> I can't imagine that we'd really want to recommend end users doing
> that, but an example would surely be taken as a recommendation
> that it's okay to do it.
Right. The language has to provide some sandbox environment for us to
consider it safe, e.g. Perl, but not Python. PL/pgSQL is safe since it
doesn't have any interface to external resources.
---------------------------
If you consider the application developer or data scientist's perspective it makes total sense. I don't like the pattern of appdevs always working as the postgres user, it encourages bad patterns and can often blow up when you move the application to production.
Instead I think a good flow for an appdev or a data scientists to follow when developing their function in Pl/Python or PL/R is:
1) Make the langauge trusted on the appdevs or data scientist's instance of Postgres. Most developers either work on a cluster on their laptop or in a container.
2) Send the finished product to the DBA and security teams for review.
3) If it passes review and testing then you can put it into production.
The SQL I am talking about is this:
UPDATE pg_language SET lanpltrusted = true WHERE lanname LIKE 'plr';There should also be a reminder to NOT do this in production.
Thanks
Steve
В списке pgsql-docs по дате отправления: