Scott Lawrence wrote:
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.
When i said test i didn't mean a junit test or alike. Instead, i meant
testing the functionality of the code written, that meaning effectively
running the check for updates and updates from the sipXconfig UI. As
Scott said, it depends on where --prefix points to when running
configure. In my case (and probably other's too), it is pointing in such
a way that the path to the error and output files returned by the
SwAdminRpc contains "../". But the problem is not only in SwAdminRpc
returning this path. In order for the XML-RPC call to retrieve the
content of a file, the path to this file has to be "published" by
sipXsupervisor (Scott, please correct me if i am wrong) so the problem
is that this path "published" by sipXsupervisor contains "../" too.
Currently there are 3 cases:
- if the path returned by SwAdminRpc is not equal to the path
"published" by sipXsupervisor, no file will be retrieved because the
asked file was not "published" by sipXconfig.
- if the paths equals, but both contain "../", an error occurs because
of the validation of the url which for security reasons must not contain
"../".
- if the paths equals and they don't contain "../" everything is ok and
it works just fine.
Looking at these cases, besides changing the --prefix when configuring,
i see only one solution (which is basically what Arjun suggested): in
SwAdminRpc.cpp or FileResource.cpp to add some code to process the
output and error files paths in order to remove the "../" sequences, and
change these paths accordingly.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
