генерал Пурпоз wrote: > > What exactly the 'apr_filepath_merge()' is supposed to do? > > In the simplest case of the "rootpath" == '/foo/bar/bla', and the > "addpath" == 'baz' the "newpath" is == '/foo/bar/bla/baz' - correct? Yup.
> If the "rootpath" == '/foo/bar/bla', the "addpath" == '../baz' - > should the "newpath" be == '/foo/bar/baz' ? Yes - UNLESS NOTABOVEROOT flag was passed. > If the "addpath" == '../../baz' - should the "newpath" be == '/foo/baz' ? Yes - except NOTABOVEROOT as above. > Is this understanding correct? > Is the "addpath" of something like '../baz/../../' allowed too > (however stupid)? Sure. The concept is that the root given must not change on output after all ./ and ../ segments are reduced when they ask for NOTABOVEROOT to be evaluated. > So, in general, first I rectify the "rootpath" NO :) We presume rootpath **was** normalized previously. We presume addpath is untrusted user data. Now come up with a path that isn't insecure per the flags the developer passed. and then I crawl > up|down the resulting rooted path and try to construct a new path > according to the "addpath"'s list of elements *FROM LEFT TO RIGHT*. Right. > After I get to the very end of the "addpath" - I copy what I got into > the "newpath". Right? Yes. > If, according to the "addpath"'s instructions, I get down to the root > I should consult the flags and either, if permitted, proceed up from > root, or return with an error. (I.e. if "rootpath" == '/foo/bar', and > the "addpath" == '../../../baz' the "newpath" is == '/baz' if flags > permit.) > > Sorry for too many questions at a time! :) No - not to many - and again refer your results against testpaths.c to see that your merge is proper. Don't be surprised that one call to a system function won't provide the features that the API demands ;-)
