Re: Untrusted PL/Tcl?

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Jan Wieck <JanWieck(at)yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Untrusted PL/Tcl?
Date: 2000-07-19 12:49:24
Message-ID: 200007191249.OAA04861@hot.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
> Tom Lane wrote:
> > JanWieck(at)t-online(dot)de (Jan Wieck) writes:
> > > Should I go for it and if so, how should this language be
> > > named?
> >
> > Sounds like a fine idea.
> >
> > While you're in there, do you want to do something about supporting NULL
> > inputs and results properly? Right now, a NULL input comes into a pltcl
> > function as an empty string, which is OK as far as it goes but you can't
> > always tell that from a valid data value. There should be an inquiry
> > function to tell whether argument N is-null or not. Also, AFAICT
> > there's no way for a pltcl function to return a NULL. The most natural
> > Tcl syntax for this would be something like
> > return -code null
> > but I'm not sure how hard it is to persuade the Tcl interpreter to
> > accept a new "-code" keyword without actually changing the Tcl core.
> > Worst-case, we could invent a new statement "return_null" ...
>
> Good idea! I think I could add a -code null by replacing the
> builtin "return" function by a custom one.

Well, I've implemented an "argisnull n" and "return_null"
command for now. So "argisnull 1" will tell if $1 is NULL or
not.

The "return -code null" would be theoretically possible. But
it might make us more Tcl version dependant than we really
want to be.

> While beeing in there, I could do something else too I wanted
> to do for some time now. It'll break backward compatibility
> to Tcl versions prior to 8.0, so if there are objections ...
>
> Beginning with Tcl 8.0, dual ported objects got used to deal

Something I had to reevaluate. All values exchanged between
PG and Tcl have to go through the type specific
input-/output-functions. So Tcl is dealing with strings all
the time. Therefore, the dual ported objects might not do for
us, what they usually do for an application. Left it as is
for now.

PL/TclU (pltclu) is in place now. I think I'll like it :-)

There's just one nasty detail. If an untrusted function wants
to load other binary Tcl modules, it needs to load
libtcl8.0.so explicitly first (to avoid unresolved symbols).
But after that, I was able to load libpgtcl.so and
connect/query another database on the first try! A DB
backend that acts as a client on another DB - not bad for a
first test. Socket operations (to GET an html page) worked
too, so a PG backend can be a web-browser now :-).

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2000-07-19 14:26:24 Re: [HACKERS] Re: PRIMARY KEY & INHERITANCE (fwd)
Previous Message Pavel Janík ml. 2000-07-19 11:18:41 Re: [HACKERS] Re: pg_dump with BLOBS & V7.0.2 UPDATED