[
https://issues.apache.org/jira/browse/SOLR-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533171#comment-13533171
]
Uwe Schindler commented on SOLR-4195:
-------------------------------------
bq. I assume you cannot just do new File(".").getAbsolutePath()?
The policy file uses a sysprop to allow write access (see the common-build.xml
and the policy file). The policy file is read by the JVM on JVM startup before
any code is run, so you cannot change the system property. Java policy files
MUST contain the full path in platform specific notation. Because of this, the
JVM working dir must be passed as absolute, platform specific path.
bq. See the 'tempdir' attribute.
The current patch uses this. But the tempDir attribute only contains the roor
dir, below which are the following files/dirs:
- one Jxxx for each JVM
- a set of files for inter-process communication
My problem is now: I can only limit to this tempDir where all above files are
in. But I want tests to be limited to a subdirectory (the Jxx one), so I want
the runner to pass a sysprop (can be any prop) with the full path of the CWD /
working dir of this JVM it has spawned. Also the test runner must be able to
write files to its inter-pocess communication folder, so I need this directory
too (as sysprop). Then the policy file would give write access to both of these
(absolute file) sysprops. I cannot do this with ANT. ANT only gives me tempDir
(what it currently uses).
The reason why i want the inter-process communication files in a separate
folder is: the policy gives write access to *all* subdirs, so also to *all* Jxx
subdirs. By having these logs/other files in a separate dir along with J0,
J1,... the 2 sysprops can give the policy file the 2 directorys that can be
written to.
> Further restrict security policy of tests to disallow writing to files
> outside the test's work dir (e.g. disallow writing to build/test-files)
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4195
> URL: https://issues.apache.org/jira/browse/SOLR-4195
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4195.patch, SOLR-4195.patch, SOLR-4195.patch,
> SOLR-4195.patch
>
>
> Until recently, I thought the solr test framework was setup such that every
> test got it's own copy of the "test-files/solr" directory to use as it's Solr
> Home Dir -- then mark committed r1421543, to fix a problem where that test
> was writing a file (that would later be removed) to the solr conf dir, which
> would confuse another currently running test and cause it to fail.
> This made me realize that what i was remembering is that the ant build files
> copy the src/test-files directories into build/ prior to running the tests --
> but all tests (in that module) still share the same copy.
> Subsequent discussions with folks on IRC lead me to the following
> realizations..
> * making a copy of the test-files dir for each test would help eliminate
> confusing by reducing non-reproducible failures if tests collide -- but might
> be slow
> * making a copy of the test-files dir for each test would not help identify
> situations were code was mistakenly/unexpectedly writing to the solr home dir
> * what would probably make the most sense, would be to make the
> build/test-files directory "read only". that way by default tests would get
> a read only solr home dir -- triggering failures if the code is broken and
> tries to write to that dir. tests that want/need to write to the solr home
> dir would have to go out of their way to clone the read only test-files/solr
> directory and use it as their solr home.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
