Menu
▾
▴
#3850 Safe interp problems with namespaces and ensembles
(Using 8.5b2 for Linux x86)
(1) Existence of namespaces
In 8.4, a freshly created safe interpreter has no namespaces apart from "::".
However, in 8.5b2, a freshly created safe interpreter has "::tcl" and its children.
This might not be inherently unsafe, but it certainly breaks assumptions that were valid in 8.4.
(2) The namespace ensemble command chan is not one of the safe commands, but it is not listed in the hidden commands either.
% interp create -safe -- bar
bar
%
% interp eval bar {info commands c*}
case catch clock concat close continue
%
% interp eval bar {chan}
invalid command name "chan"
%
% interp hidden bar
file socket open pwd glob exec encoding load fconfigure source exit cd
%
(3) More trouble with chan: exposure of its member commands.
All the commands ::tcl::chan::* are exposed, but ::chan is not one of the safe commands.
(4) Hiding a namespace ensemble command
The commands ::tcl::Info_* are exposed, even if ::info is hidden. At best, it is laborious to hide an ensemble command; at worst, you might not realize that the command is an ensemble with members in a namespace, that also need to be hidden.
% interp create -safe -- foo
foo
% interp eval foo {info commands i*}
info if interp incr
% interp hide foo info
% interp eval foo {info commands i*}
invalid command name "info"
%
% interp eval foo {::tcl::Info_commands i*}
if interp incr
%
Logged In: YES
user_id=80530
Originator: NO
The difficulties with
[interp hide] and namespaces
make this a hard one, but the
issue raised looks pretty serious.
We ought to re-evaluate how safe.tcl works
Perhaps we could discuss this at Tcl 2009 - how about a BoF session for safe interpreters?
Re-assigned to 8.5 current (previously 8.5b2)
Items (2) and (3) were bugs in 8.5b2 that have now been fixed. (1) is an observation. (4) is a design issue that is still unresolved.
The issues in this report are important, and deserve
some attention. Unless I'm missing something, though,
they have nothing at all to do with the "Safe Base" in
safe.tcl.
I have no enthusiasm at all for examining safe.tcl.
It feels like a failed an abandoned experiment to
me, and a waste of time continuing any CPR on it.
The issue that ensemblification has exposed
unsafe commands in safe interps, and that
Tcl_HideCommand()'s insistence on remaining
namespace-unaware makes it near impossible
to fix needs some resolution. Conference is
likely a good time to hold some feet to the fire.
When ensemblifying, I've been trying to make sure that I maintain the existing profile of what is and isn't safe. I've not done [file] or [encoding] yet.
BTW, the ensembles themselves probably ought to be all safe; it's the subcommands that are potentially unsafe.
Issues here are tricky enough, I can't
justify making 8.5.8 release wait for their
resolution.
[interp create -safe] currently hides all commands that are considered to default to not being safe, according to a fairly restrictive definition. The [info] command exists, but some of its subcommands are excluded. The [file] command is hidden by default, but some of its subcommands (the safe ones!) are actually present. The vast majority of [info] subcommands are *totally* safe.
[safe::interpCreate] goes further, adding a profile of commands that permits requiring of packages from blessed directories. This entails adding special versions of many commands that are generally unsafe (and I *hate* the complexity of [glob]!)
Re (1), I simply don't care. Or rather, broken old assumptions were always broken; there was simply never a promise to have only the global namespace present by default. Re (4), this is unfortunate but how it is. What we had previously was a horrible mess. It's still pretty messy, but at least we're trying to clean up the problems. THIS WILL BREAK SOME CODE. Can't be helped.
I agree that we shouldn't worry about (1), though we can lament the passing of a simpler age!
(4) is more interesting. At present, hidden commands must be in the global namespace. At the BOF at Tcl 2009, I think it was stated that this problem is fixable. It would be necessary to have a separate table of hidden commands for each namespace; and when a hidden command is exposed, although it could be given another name, it would have to be a name in the same namespace.
IIRC, it was Kevin Kenny who had the most knowledge in this area.
interp(n) states "Currently, the names of hidden commands cannot contain namespace qualifiers, and you must first rename a command in a namespace to the global namespace before you can hide it. Commands to be hidden by interp hide are looked up in the global namespace even if the current namespace is not the global one. This prevents slaves from fooling a master interpreter into hiding the wrong command, by making the current namespace be different from the global one."
If anyone understands what the writer means by the final sentence, or can provide an example of this hypothetical attack, please speak up! Until then, I'm not sure I believe this sentence.