Damian Krzeminski wrote:
> http://track.sipfoundry.org/browse/XCF-2954
> 
> Bogdan published his work-in-progress patch for switching sipXconfig
> updates to use XML/RPC. He has some questions: I thought that posting on
> the list might bring some useful comments:
> 
> Here it is:
> 
> <quoting from Bogdan's update>
> 
> - first of all, i had to modify the HttpServer.cpp in sipXtackLib project
> and to bypass some filename uri enforcing. As i saw in code, for security
> reasons, the request to retrieve published files that have filenames
> containing ".." will fail. But the problem is that the files published by
> sipXsupervisor (containing the stdout and stderr of the updates-relative
> command invoked) are published with path relative to the BUILD directory,
> containing ".." .
> 
> In order to test the functionality of the patch I bypassed the enforcing in
> HttpServer.cpp, but i think that the files should be published with their
> absolute path rather than relative path.
> 
> For example instead of:
>  "/home/user/work/BUILD/../INSTALL/somedir/../anotherdir/file.err"
> 
> it should be published as
>  "/home/user/work/INSTALL/anotherdir/file.err"
> 

Bogdan,

Here, I assume you mean the path that SwAdminRpc returns (after exec-ing the 
XML-RPC call) is formatted as 
"/home/user/work/BUILD/../INSTALL/somedir/../anotherdir/file.err".. This 
doesn't really happen in my environment, which has the following folder 
hierarchy:

/home/anair/sipx/
   |-- src
   |-- build
   |-- install

But, if this is indeed happening in your env, then we could possibly add in 
code to SwAdminRpc, which would format out any "../" before returning the path 
to the caller.

Arjun

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

Reply via email to