search

binarycrusader / libproxy

Automatically exported from code.google.com/p/libproxy
GNU Lesser General Public License v2.1
0 stars 0 forks source link

proxy command fails in test suite on ubuntu 8.04 and fedora 9, but not ubuntu 8.10 #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.) Update to the latest svn trunk
2.) On Ubuntu 8.04, Ubuntu 8.10, and Fedora 9, build libproxy and then
execute ./runtestsuite.sh

Ubuntu 8.10 looks good and the other distros fail the test. Why?

What is the expected output? What do you see instead?
===== Ubuntu 8.10 =====
TEST NAME            STATUS
proxy_and_lib:           [PASS]
test_env_var1:           [PASS]
=======================

===== Ubuntu 8.04 =====
TEST NAME            STATUS
proxy_and_lib:           [PASS]
*** Unable to locate valid config! Falling back to auto-detection...
*** Unable to locate PAC! Falling back to direct...
test_env_var1:           [FAIL] - src/bin/proxy returned direct:// instead of
http://proxy:1234
=======================

======= Fedora 9 ======
TEST NAME            STATUS
proxy_and_lib:           [PASS]
*** Unable to locate valid config! Falling back to auto-detection...
*** Unable to locate PAC! Falling back to direct...
test_env_var1:           [FAIL] - src/bin/proxy returned direct:// instead of
http://proxy:1234
=======================

The actual command being ran is:
PX_CONFIG_ORDER=envvar http_proxy="http://proxy:1234" src/bin/proxy
http://www.google.com

Original issue reported on code.google.com by jeffschroed on 17 Dec 2008 at 6:00

GoogleCodeExporter commented 9 years ago 
Jeff,

I 'think' to know what happens and this actually put's the entire testsuite 'at 
risk'.
Let me first tell you my assumption:

Ununtu 8.10 is your main system
the others you tested are either just installed VMs or seperat systems.. but 
not your
main systems.

On Ubuntu 8.10, you az least once executed make install, but you never did so 
on the
other boxes.

The 'flaw' is actually, that libproxy does not find it's plugins if make 
install was
never executed, as on compile time the path is being compiled inside the lib.

and ldtools played a naugty trick on us: src/bin/proxy is actually NOT the built
proxy binary, but a lintool shell script wrapper, that takes care of creating 
the
LD_LIBRARY_PATH suitable for it to find libproxy.so.. otherwise this should 
actually
already fail there.

So in short:
The test suite CAN'T work if make install is not executed.

(very bad: in this case I'll never be able to activate the testsuite during RPM
building on openSUSE for example, as make install is being redirected using 
DESTDIR=
and in this case libproxy.so won't find it's plugins and it would fail out.

Original comment by Marina.M...@gmail.com on 18 Dec 2008 at 5:52

GoogleCodeExporter commented 9 years ago 
We know of this drawback and are attempting to address this using ctest.  The 
module
problem will be (somewhat) solved by loading the modules directly now that 
libmodman
is isolated.  We will still have problem testing proxy.cpp though.  There is 
not much
I can do since adding runtime module directory support is the limiting feature. 
 This
feature cannot be added because it is a security risk.

We may perhaps come up with two different build configurations.  For instance a
"Debug" config which uses modules in the build directory and then a "Release" 
config
for actually building a release.  We can perhaps test this way.

Original comment by npmccallum@gmail.com on 17 Feb 2010 at 1:50

GoogleCodeExporter commented 9 years ago 
As discussed before, I think considering an environment variable to configure 
this 
path as being a security risk is same as considering LD_LIBRARY_PATH being a 
security 
risk.

A security issue would be set a relative path. An old example is the infamous 
"." in 
PATH. On a multi user system, if you can get somebody to 'cd' into a certain 
directory and then to run one of your script instead of let say 'ls', you can 
gain 
control over the user account.

Attached a patch that enable the module path and the pxgconf command path to be 
configured through environment variables (PX_MODULE_PATH, PX_GCONF).

Code can also be cherry picked from my git repo:

# PX_MODULE_PATH
http://git.collabora.co.uk/?
p=user/nicolas/libproxy.git;a=commitdiff;h=5856cc36b477459e1c94263a21713f3065524
eb9;h
p=5d1a9109d2520979bf758671f82e868abe5b1c09

# PX_GCONF
http://git.collabora.co.uk/?
p=user/nicolas/libproxy.git;a=commitdiff;h=4b986241b47d80cce7825d816ba40e18f522d
12f;h
p=5856cc36b477459e1c94263a21713f3065524eb9

Original comment by nicolas.dufresne@gmail.com on 24 Mar 2010 at 6:35

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
The patches.

Original comment by nicolas.dufresne@gmail.com on 24 Mar 2010 at 8:33

Attachments:

GoogleCodeExporter commented 9 years ago 
Configuration env as been added in r648, r649. Use PX_MODULE_PATH for the path 
where 
modules are, and PX_GCONF for the location of pxgconf utility.

Original comment by nicolas.dufresne@gmail.com on 31 Mar 2010 at 11:43

GoogleCodeExporter commented 9 years ago

Original comment by nicolas.dufresne@gmail.com on 18 May 2010 at 3:11