On Thu, Apr 13, 2006 at 01:22:55PM +0200, Ludovic Court?s wrote: > Hi, > > "Andy Tai" <[EMAIL PROTECTED]> writes: > > > OK, once Tom has spoken, that's it. I will follow Tom's suggestion > > here. Pedro, please just use the path without the dot in front. > > Beside Tom's authority, I believe the rationale is that paths in configs > should be relative to the tree root and should only designate locations > _within_ that tree root. Hence, it is a good thing for a path starting > with `..' to be rejected. Same for an absolute path. > > Now, it seems that `is_non_upwards_relative_path ()' would also reject > paths like `chbouib/../foo' which theoretically it should accept. But > well, arguably, that shouldn't be too much of a problem. ;-)
There is something to be said for passing the paths through a canonifying function (remove all /./ and /foo/../ from the path). That retains the security benefits and avoids issues with no-ops. This one falls under 'liberal in what you receive', it's quite plausible that configs could be generated by some other code and thusly be in non-canonical form. In the real world, /./ happens because one piece of software wanted a directory there, but the user didn't, so they supplied a periot instead. Consider './configure --prefix=.' - you can't use the empty string, because '/foo' and './foo' are different. That's more or less why unix has the '.' directory name: it's a *useful* no-op for connecting pieces of software together. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
