Untrusted PL/Tcl?

Jan Wieck wrote:

capabilities. This one would be installed as an untrusted PL,
so only DB superusers could create functions in that
language.

Should I go for it and if so, how should this language be
named?

Yes; pl/utcl. Or pl/tclu. :-) Those facilities would be nice to have.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"J" == Jan Wieck <JanWieck@t-online.de> writes:

J> there have been a couple of questions WRT doing untrustable
J> things like file access, LDAP and the like from inside of
J> triggers or functions.

With PL/Ruby you can do this by giving the option --with-safe-level=number
at compile time.

Safe level must be >= 1, you just need to comment the line :

rb_set_safe_level(1);

in plruby_init_all(), if you want to run it with $SAFE = 0

Guy Decoux

JanWieck@t-online.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" ...

regards, tom lane

Tom Lane wrote:

JanWieck@t-online.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.

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
with values. These have (amongst performance issues) alot of
benefits. Changing all the call interfaces would make it
impossible to use PL/Tcl with a pre 8.0 Tcl installation.
Since we're now at Tcl 8.3 (the last I've seen), ISTM it's
not a bad decision to force the upgrade.

Comments?

Jan

--

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

JanWieck@t-online.de (Jan Wieck) writes:

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
with values. These have (amongst performance issues) alot of
benefits. Changing all the call interfaces would make it
impossible to use PL/Tcl with a pre 8.0 Tcl installation.
Since we're now at Tcl 8.3 (the last I've seen), ISTM it's
not a bad decision to force the upgrade.

OK by me. Tcl 7.6 is getting to be ancient history... and people
who are using pltcl for database functions are probably going to
want all the speed they can get, so making a more efficient interface
to Tcl 8 seems like a good idea.

regards, tom lane

Jan Wieck wrote:

Tom Lane wrote:

JanWieck@t-online.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@Yahoo.com #

Jan Wieck wrote:

Mikhail Terekhov wrote:

Do you plan to make libpgtcl stubs enabled? In this case it would be
possible to use any version of tcl, at least any 8.*>8.05. It seems that
this is not hard to do, see http://dev.scriptics.com/doc/howto/stubs.html

Seems you mixed up some things here.

PL/Tcl is a "procedural language" living inside of the
database backend. One can write DB-side functions and trigger
procedures using it, and they are executed by the DB server
process itself during query execution.

These functions have a total different interface to access
the DB they are running inside already.

Ok

This all has nothing to do with a Tcl script accessing a
Postgres database as a client application. It's totally
unrelated to libpgtcl! Even if the changes I committed today

Right

enable a backend, executing a PL/TclU (a new language)
function, to become the client of another database using
libpgtcl now - to make the confusion perfect.

PL/Tcl and libpqtcl have one important thing in common - they use
Tcl library. The purpose of stubs mechanism is to make applications
which use Tcl library independent from the Tcl version as much as
possible. The bottom line is that if you want your PL/Tcl or PL/TclU
or libpgtc to be linked with the Tcl dynamically, then there is a
possibility that due to version mismatch they will not work after
upgradig/downgrading Tcl. So it is better to use stubs to avoid this.

Mikhail