Hi Olivier,
On Tue, 2006-03-07 at 22:57 +0100, Olivier Jolly wrote:
> the current implementation which retrieves a File resource allows to
> retrieve Files which are located "above" the root dir (imagine
> ClassLoader.getResource("../../../etc/passwd")) while it shouldn't
> (hence the current regression in
> gnu.testlet.java.net.URLClassLoader.getResource about '..').Nasty. Good catch. > I propose to check the validity of a File resource by walking through > all the path components and making sure that all intermediate components > are valid (ie File.isDirectory and File.exists are true) and that we > never try to get "out" the root directory. > I only consider ".." as a way to escaping the root directory, it may > be more complex than that ... ".." seems a good heuristic. I assume much more will break on any platform were ".." isn't "up in the file hierarchy". > I also think that extracting the path components could be improved > from a performance point of view, maybe working on the char[] > representation instead of using charAt and storing the length once for > all. I was thinking about using a StringTokenizer but it doesn't handle > '//' as a single separator and split & cie are 1.4+ additions. You can use 1.4+ additions as long as we have implemented them. The only real exceptions are Graphics2D and things that need 1.5 language features. Our Graphics2D is just not mature enough to let anything really depend on it and the 1.5 language features can only be used on the generics branch atm. The implementation seems correct, but as you say it could be made more efficient. You could do the walking over the char[] or use String.indexOf(File.separatorChar, currentIndex) to get more efficiently at the next token. And I would try to get rid of the recursion by keeping track of the last separator position you saw. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
