A point of contention among the 4Suite developers is how an FtssInputSource should go about resolving a URI having the 'file' scheme. For example, if an XML document in the repository contains
<?xml version="1.0" encoding="utf-8"?> <data><xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="file:///etc/passwd" parse="text"/></data>
then the result of retrieving this document will be, assuming the server has access to local file /etc/passwd, the contents of /etc/passwd.
FtssInputSource is intended to be, primarily, an interface to resources that are in the repo. If it is asked to resolve a URI that is not of the 'ftss' scheme, then, as of 4Suite 1.0a1, it will do one of the following:
- reject the URI based on the scheme being forbidden outright (e.g. 'file');
- resolve the URI via the standard InputSource class, when the URI's context is one that's allowed (e.g., XSLT's document function);
- map the URI to an 'ftss' URI and resolve it by attempting to fetch the appropriate resource in the repository
The example XML above cannot even be loaded into the repo now without generating an exception: "URI file:///etc/passwd cannot be converted to a repo (ftss) URI".
The disagreement is in whether the 'file' scheme should ALWAYS be disallowed. Some background discussion on this can be found in these posts:
- Jeremy doesn't like the security risk and suggests 'file' URIs should always map to 'ftss' URIs. MikeO agrees.
- Uche says security policy should be configurable and that 'file' URIs should only map to 'ftss' URIs if they specify a particular hostname.
- MikeO agrees on security but prefers simple on/off options for 'file' support and he feels Uche's 'file://4ssrepo/' proposal is too confusing.
- Uche continues to advocate more configurability than just on/off
- MikeB suggests disabling 'file' support until the need for local file access from repo docs can be better justified. Uche counters that he and Evan Lenz have a need for local file access right now
- After MikeB arbitrarily forces 'file' URIs to resolve to repo resources, as part of more sweeping improvements and fixes in 4Suite's URI handling, Uche protests. A long discussion on IRC results in mutual understanding and agreement on what is really needed: a completely separate URI scheme for repo resources. Research into a good scheme name and how to register it ensues.
The 'ftss' scheme became a reality in early January 2003. Efforts were made to adjust all URIs for repo resources, including the URIs in RDF statements, to use the new scheme, but as of the 4Suite 1.0a1 release on March 27, it had not yet been completed. Nothing conclusive was decided about how to handle 'file' URIs.