Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
3) Parrot itself (the main executable) has a static, global 1K buffer in it that starts and ends with some recognizable string (like, say, "***+++***START|" and "|END***+++***") so we can find it and overwrite the contents if the library gets moved, for use on platforms where the only way to put a path in is to stick it statically in the executable.
That's pretty disgusting, but I don't know that I have a better idea.
There isn't one, alas, at least for some people.
Everyone running tripwire, et al. (or simply md5sum'ing files to verify integrity) will just love this strategy to death.
Finding resource and library files relative to the binary really is a very good strategy. Windows is adopting the placed-near-the-binary strategy for locating resources and libraries. It has completely eliminated "DLL hell" for .NET programs. Mac OS 7 through X have all used the same strategy. They have never had major problems with library or resource location. Looks like a strong precedent and a proven technique.
Of course, one can find pathological cases—especially on Unix, which seems designed to thwart this sort of easy-to-administer technology:
• parrot binary unlink'd between exec and main(). (Can't happen on Windows.)
• Launched through a symlink to the binary.
• Launched through a hard link to the binary.
• bin/ is a symlink, so ../share won't work.
• Platform can't find the binary. (Can't happen on Windows, Linux, or Mac OS X.)
• chroot (which, in general, near-the-binary solves rather than complicates).
But I'd say these are all are heavily outweighed by the advantages. And, in any case, it's a trivial matter at this point in design to offer support for replacing a call to Parrot_get_bin_path() (or whatever) with "/usr/local/bin" at configure time. That resolves all of the above. With a loss of functionality, true, but: Users on platforms which can't support this feature won't after all expect /opt/parrot to work after it was mv'd.
As for the security concerns of trusting anything but one's current binary*, parrot could adopt a cryptographic solution for verifying integrity of resource files, if anybody's really all that worried about an errant Unicode character database.
—
Gordon Henriksen [EMAIL PROTECTED]
* - Is the binary itself is really all that trustworthy in the first place? If a user is executing a program through an untrusted or compromised path, they're already putting their life in their hands, and accessing ${bin}/../share won't make the configuration any more trustworthy.
