> Scott Lawrence wrote: > > 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. > >
On Tue, 2009-04-14 at 13:00 +0300, Bogdan Brezoi wrote: > 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. FYI - the sipXsupervisor will (at present) allow access only to files whose path is listed in some process description file. It can be listed as a 'file' or 'osconfig' resource, or as a log file. At some point, we'll probably want to add some form of pattern matching and/or directory access specifiers (eg. "allow access to any file in directory x/y/z, or any file matching /x/y/*.z), but that is not there now. I'm not sure that this kind of test actually qualifies as a 'unit test' - it is actually testing multiple components simultaneously. I think that unit tests should strive to test exactly one component (or less - test only parts of the code within a component) by simulating other components rather than actually using them. In this case, if the test were simulating the supervisor then this path issue would not arise. This really isn't a unit test - it's a mini-system test, which is much harder (we have _lots_ of problems with this kind of test in the server side). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
