On Mon, 2009-04-13 at 10:30 -0400, Arjun Nair wrote: > 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.
The difference is in where you put the build tree (where you run the 'configure' script) and the install tree (what '--prefix' points to when you run configure). Many combinations are possible, and as far as I can tell the developers on this project use every legal combination :-) (which is a good thing - it keeps us all honest). If the test were to construct the path using a function that provides a direct (no /../) to the real location, I think things would work fine. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
