From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Joe Conway" <mail(at)joeconway(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Stephen Frost" <sfrost(at)snowman(dot)net>, "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:01:27 |
Message-ID: | 87odimb4yw.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Joe Conway" <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2007-07-09 04:07:34 | Re: dblink connection security |
Previous Message | Stephen Frost | 2007-07-09 03:57:17 | Re: dblink connection security |