From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
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>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: dblink connection security |
Date: | 2007-07-01 21:59:50 |
Message-ID: | 468823D6.6000104@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway wrote:
> Robert Treat wrote:
>>>> Joe Conway <mail(at)joeconway(dot)com> writes:
>>> Well certainly dbi-link has the exact same issue.
>> dbi-link only works in plperlu, so you've already decided your superuser only.
>
> How so -- it is fundamentally no different than dblink, which is C
> language (also untrusted).
>
> I think the issue is that once the superuser creates said functions,
> usage of the functions is automatically granted to PUBLIC, no? Being an
> untrusted language just means that it takes a superuser to create the
> functions using that language, not to use the functions themselves.
In fact, this misconception can prove dangerous in other ways. From the
docs:
CREATE FUNCTION badfunc() RETURNS integer AS $$
my $tmpfile = "/tmp/badfile";
open my $fh, '>', $tmpfile
or elog(ERROR, qq{could not open the file "$tmpfile": $!});
print $fh "Testing writing to a file\n";
close $fh or elog(ERROR, qq{could not close the file "$tmpfile": $!});
return 1;
$$ LANGUAGE plperlu;
select usename, usesuper from pg_shadow;
usename | usesuper
----------+----------
postgres | t
foo | f
(2 rows)
contrib_regression=# \c - foo
You are now connected to database "contrib_regression" as user "foo".
contrib_regression=> select badfunc();
badfunc
---------
1
(1 row)
So anyone thinking that just because a language is untrusted means that
they don't need to be careful, is mistaken.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-01 22:13:18 | Re: dblink connection security |
Previous Message | Gregory Stark | 2007-07-01 21:54:00 | Re: dblink connection security |