Thread: Untrusted PL/Tcl?
Hi all, there have been a couple of questions WRT doing untrustable things like file access, LDAP and the like from inside of triggers or functions. Tcl is a powerful language and could do all that, but the interpreter used in PL/Tcl is a safe one, because it is a trusted procedural language (any non-superuser can create functions). I think it should be pretty easy to build a second PL handler into the module, that executes the procedures in a full featured Tcl interpreter,that has all 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? 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: > 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=numberat 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 likereturn -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 mightnot 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 anotherDB - not bad for a first test. Socket operations (to GET an html page) worked too, so a PG backend can be aweb-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