Re: dblink connection security - Mailing list pgsql-patches

From Gregory Stark
Subject Re: dblink connection security
Date
Msg-id 87odimb4yw.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: dblink connection security  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
"Joe Conway" <mail@joeconway.com> writes:

> Agreed.
>
> 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.

Only if the function created uses some facility of the untrusted language that
we wouldn't want any arbitrary user to have access to without explicitly
granting it.

Privilege escalations like this are a serious problem. I am pretty confident
that if this is left like this it will come up again in the future by someone
else reporting it as a security hole again.

> 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.

And the author of the script here is not being careful in this respect. The
sysadmin isn't the one writing the create function statement.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-patches by date:

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