Re: dblink connection security - Mailing list pgsql-patches

From Stephen Frost
Subject Re: dblink connection security
Date
Msg-id 20070709035528.GR4887@tamriel.snowman.net
Whole thread Raw
In response to Re: dblink connection security  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
* Joe Conway (mail@joeconway.com) wrote:
> If you are going to argue that we should revoke access for non-superusers
> by default for dblink, then you are also arguing that we should do the same
> for every function created with any untrusted language.

Uh, no, one doesn't imply the other.  It doesn't follow that because a
specific, known insecure, function shouldn't be available to all users
immediately that quite probably safe/secure functions (even though
they're written in an untrusted language- what has that got to do with
anything?) also shouldn't be.

> E.g. as I pointed out to Robert last week, just because an unsafe function
> is created in plperlu, it doesn't mean that a non-superuser can't run it
> immediately after it is created. There is no difference. It is incumbent
> upon the DBA/superuser to be careful _whenever_ they create any function
> using an untrusted language.

This isn't a case of the DBA/superuser writing the function.  It's being
provided by a package.  It's also *inherently* insecure and isn't just a
matter of "being careful".  You can create functions in an untrusted
language carefully enough to allow it to be called by other users.  It
is simply prudent for the package provider to disable insecure functions
by default.

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink connection security
Next
From: Stephen Frost
Date:
Subject: Re: dblink connection security