Actually, one thing I'd like to see is if it wasn't the library's base
path hardcoded in, but the base path of a frozen data structure or
program that encoded Parrot's settings. That would allow it to carry
the runtime library path, the paths to ICU's tables, the paths to search
for PMCs, and whatever else we can think of, without a hardcoded limit.
This wouldn't be a bad thing, nope. I could see security issues--it'd probably be better to link the config file right into parrot.
There'll be the same security issue with anything located on the filesystem--the config is not particularly worse than anything else (DLLs, etc.). The security of anything you run is only as good as the integrity of the filesystem used to locate the resources. (Specifically, if I were a hacker and could compromise your system by replacing the config, I just as easily replace parrot itself.) But it would be nice to "bake in" things which you can't really change without rebuilding anyway--thinks like UINTVAL size, etc. Monkeying with them after-the-fact would be a definite security risk (buffer overruns, etc.), and wouldn't ever be useful. But stuff like finding ICU's data files (or add-on libraries) we'd want to be easily changeable without a rebuild. (And again, if you have to rebuild to change them, then people will tend to keep around the tools needed to do that, which would give a hacker the tools they need to do the same.) But we certainly need to define/articulate a security model, no matter what approach we take. (But my gut reaction is always against something which decreases flexibility, and only _seems_ to increase security.)
But there of course are security issues with anything located relative the the cwd(). (That is, if resources are located relative to the cwd, then I can trick you into loading my copies by taking you into chdir-ing into my home directory.)
JEff
