[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: Porting APR to QNX4: portability problems.
From:       "William A. Rowe, Jr." <wrowe () rowe-clan ! net>
Date:       2007-01-31 4:46:57
Message-ID: 45C01F41.9060405 () rowe-clan ! net
[Download RAW message or body]

генерал Пурпоз 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 ;-)
[prev in list] [next in list] [prev in thread] [next in thread]