Can I make special permissions for procs?

Luc

unread,

Sep 21, 2022, 5:52:35 PM9/21/22

to

I know this sounds odd, but please bear with me.

I have this app that can load up and parse a Tcl file. That file is supposed to contain Tcl procs created by the user. Not only that, the user gets to run any one of those procs in a certain context, with a certain purpose.

That is very nice and flexible, but it would be unfortunate if the user created a proc that has the same name as another proc that already exists in the application itself. I don't want that to happen.

So I decided to create a namespace, and all the application's internal procs belong in that namespace. It is still possible for the user to create and load a proc with an existing name including the namespace, but the likelihood of that happening now is extremely small unless the user reads the source code and does that on purpose.

Not a big deal if that happens, but this scenario got me thinking: what if I want to take even further action to prevent the user from doing that? Can I create some kind of mechanism that will separate the internal procs from the external procs in a more enforceable way? Some kind of hierarchy and isolation?

It is not very important, I can go ahead without it, but I am curious to know if there is any way to do it.

TIA

Christian Werner

unread,

Sep 21, 2022, 6:04:20 PM9/21/22

to

How about giving your users a child (formerly known as slave) interpreter by using the "interp create" command? And additionally using interp aliases in order to expose the infrastructure of the enclosing parent (formerly known as master) interpreter you like to be used by your users?

HTH,
Christian

Robert Heller

unread,

Sep 21, 2022, 9:53:24 PM9/21/22

to

I believe there is something call a "safe" interpreter. I believe this means
that the interpreter is (intentionally) "missing" some procedures -- ones that
are potientally "dangerious".

man 3tcl interp

interp create ?-safe? ?--? ?path?

>
> HTH,
> Christian
>
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Luc

unread,

Sep 22, 2022, 11:06:37 AM9/22/22

to

On Wednesday, September 21, 2022 at 10:53:24 PM UTC-3, Robert Heller wrote:

> At Wed, 21 Sep 2022 15:04:17 -0700 (PDT) Christian Werner wrote:
>
> > How about giving your users a child (formerly known as slave) interpreter by
> > using the "interp create" command? And additionally using interp aliases in
> > order to expose the infrastructure of the enclosing parent (formerly known
> > as master) interpreter you like to be used by your users?
> I believe there is something call a "safe" interpreter. I believe this means
> that the interpreter is (intentionally) "missing" some procedures -- ones that
> are potientally "dangerious".
>
> man 3tcl interp
>
> interp create ?-safe? ?--? ?path?

The problem with a safe interpreter is that it has restrictions. Given that the user is supposed to be completely free to code whatever they want in their own custom procs, I probably don't want those restrictions. I just to avoid proc name conflicts.

Robert Heller

unread,

Sep 22, 2022, 11:16:59 AM9/22/22

to

OK, so long as the users are 100% trust worthy (not just not malicious, but
skilled enough not the write buggy code that crashes everything). I'd still
suggest using a safe interpreter, and use some of the features to allow "safe"
versions of the potientally "dangerious" procedures. Your users will get a
fully functional interpreter, but with safeguards so they can't "crash"
things, even by mistake. Read the man page carefully.

Mike Griffiths

unread,

Sep 22, 2022, 5:23:35 PM9/22/22

to

You can always rewrite [proc] itself to add this protection. rename proc _proc, then _proc proc {name args} {...} to write a variant that can check [info proc] to see if it exists already and fail if so, and uplevel _proc $name $args to run the "real" proc if not. (You may potentially want to cache [info proc] initially and check against that list so the user can overwrite their own procs without being able to overwrite pre-existing ones.)

Rich

unread,

Sep 22, 2022, 9:43:53 PM9/22/22

to

Safe interpreters are just a special subset of secondary interpreters.
If you don't make them 'safe' then they are fully functional Tcl
interpreters.

But they are /isolated/ -- which seems to have been what you were
looking for.