Thread
-
Untrusted PL/Tcl?
Jan Wieck <janwieck@t-online.de> — 2000-07-18T11:36:22Z
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 # -
Re: Untrusted PL/Tcl?
Lamar Owen <lamar.owen@wgcr.org> — 2000-07-18T11:54:41Z
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
-
Re: Untrusted PL/Tcl?
Tom Lane <tgl@sss.pgh.pa.us> — 2000-07-18T14:52:20Z
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
-
Re: Untrusted PL/Tcl?
Jan Wieck <janwieck@t-online.de> — 2000-07-18T16:33:06Z
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 # -
Re: Untrusted PL/Tcl?
Tom Lane <tgl@sss.pgh.pa.us> — 2000-07-18T20:55:01Z
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
-
Re: Untrusted PL/Tcl?
Jan Wieck <janwieck@t-online.de> — 2000-07-19T12:49:24Z
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 # -
Re: Untrusted PL/Tcl?
Mikhail Terekhov <terekhov@emc.com> — 2000-07-19T19:06:09Z
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