ExecutorTest on linux fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. checkout current trunk from svn on a unix/linux system
2. run mvn -Dtest=ExecutorTest test
3.

What is the expected output? What do you see instead?
Test should succeed. Test fails

What version of the product are you using? On what operating system?

Trunk revision 700

Please provide any additional information below.

There are four causes to this test failure. Two of them relate to the
platform dependent ESAPI.properties:

1.
Executor.ApprovedExecutables=C:\\Windows\\System32\\cmd.exe,C:\\Windows\\System3
2\\runas.exe
When the ExecutorTest tries to run /bin/sh it fails as this is not in the
list of approved executables.

2. Appending or changing the ApprovedExecutables is insufficient as many
unix/linux systems have /bin/sh sym linked to a different executable
(Debian sid points to /bin/bash or /bin/dash depending on your configs).
This also causes the test to fail.

3. Executor.WorkingDirectory=C:\\Windows\\Temp
As this is unusable as a working directory on most unix/linux systems, this
test fails.

4. There are four seperate calls to executeSystemCommand. The first and the
third are identical except that the first expects it to work without
exception and the third expects it to fail with an exception. I see no
difference between the two but perhaps I am missing something.

Attached is a patch that is one viable solution to these problems. It
includes a SecurityConfigurationWrapper that just wrapps requests to
another SecurityConfiguration. This allows for a easy replacement of
properties at test run time.

With such in hand, the patch get's the canonical path for /bin/sh and
replaces the allowed executables with this fixing 1 & 2 above. Similarly it
replaces the working directory with /tmp fixing 3 above.

Lastly, the patch removes the duplicate, yet contradictory, test discussed
in #4.

As this patch uses a different implemenation of SecurityConfiguration, the
issue discussed in issue 40 needs to be fixed first or the test fails with
a ClassCastException.

It seems like there should be a way to configure esapi in a non-platform
dependent manner. This is especially problematic with proposals for 2.0
including a esapi properties in the jar. Deployment of the jar on a
different platform would require external configurations or modification of
the jar itself. The latter would cause issues with jar signing or policies
forbidding librarys from being modified. Is there a way around this problem
that I am not seeing?

Thanks

Original issue reported on code.google.com by schal...@darkmist.net on 20 Oct 2009 at 3:10

Attachments:

• trunk-executortest-fix.patch

[GoogleCodeExporter]

This needs to be resolved for 2.0

Original comment by chrisisbeef on 29 Oct 2009 at 5:17

• Added labels: Priority-Critical, Milestone-Release2.0, Component-Logic, Usability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Patch applied with changes in revision 750. The patch was modified to support 
recent
additions to the SecurityConfiguration interface and comment out @Override on 
methods
implementing an interface which is not always supported for 1.5 compilers.

Original comment by schal...@darkmist.net on 4 Nov 2009 at 8:18

• Changed state: Fixed