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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

At Wed, 21 Sep 2022 15:04:17 -0700 (PDT) Christian Werner <undroidwish@gmail.com> 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?

HTH,
Christian

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

At Thu, 22 Sep 2022 08:06:34 -0700 (PDT) Luc <lucmove@gmail.com> wrote:

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 22 September 2022 at 16:06:37 UTC+1, Luc wrote:

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.

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.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Luc <lucmove@gmail.com> wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)