Re: dblink connection security

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: dblink connection security
Date: 2007-07-09 04:30:37
Message-ID: 20070709043037.GU4887@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

* Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
> "Joe Conway" <mail(at)joeconway(dot)com> writes:
> > Consider a scenario like "package <x> uses <arbitrary function y in an
> > untrusted language z>". Exact same concerns arise.
>
> Well arbitrary function may or may not actually do anything that needs to be
> restricted.
>
> If it does then yes the same concerns arise and the same conclusion reached.
> That users should be granted permission to execute it based on local policies.
> Certainly granting execute permission to public by default is a bad start in
> that regard.

Agreed, and regardless of the sysadmin doing x, y, or z, or what some
other package might be doing with untrusted languages, what matters here
is what we're doing and the functions we're providing. Best practice is
to disable functions by default which aren't safe & secure for users to
have access to.

If you know of any others in anything we're distributing, please point
them out. If there are some in related projects, point those out and
ask those projects to be careful with them and encourage them to disable
them by default.

Thanks,

Stephen

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2007-07-09 04:35:34 Re: dblink connection security
Previous Message Gregory Stark 2007-07-09 04:22:19 Re: dblink connection security