On Fri, 2009-10-23 at 17:31 -0400, Dale Worley wrote:
> (I jumped the gun by filing a Jira on this.)
> 
> I'm running into an odd problem:  You can't take a snapshot with the Web
> interface if the SIPX_TMPDIR directory's name contains a '..' component.
> 
> Here's the details:
> 
>         Taking a snapshot through the web UI fails if SIPX_TMPDIR
>         contains a '..' component. This is because the snapshot
>         operation has two parts: The first is an XMLRPC requesting the
>         snapshot be taken, which returns the absolute file name of the
>         file containing the snapshot, which is
>         SIPX_TMPDIR/sipx-configuration.tar.gz. The second step is to
>         retrieve the file with an HTTPS GET. But if SIPX_TMPDIR contains
>         a ".." component, the HttpServer object in sipXsupervisor
>         refuses to service the request. (See HttpServer::processRequest
>         line 396.)
>         
> One solution to this problem is to say "Don't!", as usual deployments do
> not need to have '..' in any of the SIPX_* directory names.

If you're using a development build, which is the only way to get this
error, there are at least two ways to avoid this problem:

     1. Use fully qualified path names when constructing your
        installation tree.   I believe that the EDE doesn't do this
        right now, but it could be fixed to figure out the correct path
        and specify it without any dots.
                
     2. Take your snapshots from the command line.  Anyone using a
        development build should be able to handle this.

> Another possibility would be to handle '..' more intelligently by making
> sure that it is not used to "escaped" a set of mapped files.
> 
> Another problem is that if a file's name contains '..' in any component,
> it will not be accessible, since the test in question is whether the URI
> contains the substring "..".

The test in the http server is not very clever, but it has the virtue of
being simple.  Again, '..' doesn't appear in any path components we care
about anyway, so this is only a hypothetical problem.


_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to