[
https://issues.apache.org/jira/browse/LUCENE-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606733#comment-14606733
]
Hoss Man edited comment on LUCENE-6542 at 6/30/15 12:35 AM:
------------------------------------------------------------
Uwe: -I'm still not following why my attempts at Runtime control over the
allowed FilePermissions don't work, but that may all be moot so let's ignore it
for now...-
*EDIT:* ah ... just saw rmuir's reply ... still wrapping my head arround 9-1
and 9-4, but i think i'm getting the gist -not going to worry about it
until/unless we decide any of the rest of the objectives below make sense...
bq. I don't see this as a bug: Lucene "owns" the directory, so it must be able
to create/delete/fsync/whatever it. If the directory is on a read-only FS and
you just open DirectoryReader, its perfectly fine if the directory exists (no
OS error). It is just FilePermission that complains.
...my main concern is this: For all the same reasons rmuir mentioned / put the
effort into LUCENE-6238, we should try to be as restrictive as possible in what
Permissions the various Lucene classes require to run. Testing wit ha "no
writes allowed" security policy like Trejkaz describes seems like a totally
legitimate thing for a user to want to do. If that's no supported -- then how
can/should users like Trejkaz write tests to verify that their usage of lucene
will not attempt to write to a (logically) read only index w/o using
restrictive FilePermissions in their tests?
You _say_ a read only FileSystem will work, and i believe you -- but how can we
_prove_ that in a lucene test so that we don't inadvertently add some silly
code to IndexReader that writes a file to the index Directory? Just depending
on something like Files.setPosixFilePermissions in the test doesn't really seem
like enough -- since the silly code might force the file to be writable first.
So short of a test that requires you have a prebuilt index on a filesystem
that's mounted read only, how do we (or our users) write/run a test to be sure
that the "read only" code in lucene is truely "read only" ?
was (Author: hossman):
Uwe: I'm still not following why my attempts at Runtime control over the
allowed FilePermissions don't work, but that may all be moot so let's ignore it
for now...
bq. I don't see this as a bug: Lucene "owns" the directory, so it must be able
to create/delete/fsync/whatever it. If the directory is on a read-only FS and
you just open DirectoryReader, its perfectly fine if the directory exists (no
OS error). It is just FilePermission that complains.
...my main concern is this: For all the same reasons rmuir mentioned / put the
effort into LUCENE-6238, we should try to be as restrictive as possible in what
Permissions the various Lucene classes require to run. Testing wit ha "no
writes allowed" security policy like Trejkaz describes seems like a totally
legitimate thing for a user to want to do. If that's no supported -- then how
can/should users like Trejkaz write tests to verify that their usage of lucene
will not attempt to write to a (logically) read only index w/o using
restrictive FilePermissions in their tests?
You _say_ a read only FileSystem will work, and i believe you -- but how can we
_prove_ that in a lucene test so that we don't inadvertently add some silly
code to IndexReader that writes a file to the index Directory? Just depending
on something like Files.setPosixFilePermissions in the test doesn't really seem
like enough -- since the silly code might force the file to be writable first.
So short of a test that requires you have a prebuilt index on a filesystem
that's mounted read only, how do we (or our users) write/run a test to be sure
that the "read only" code in lucene is truely "read only" ?
> FSDirectory throws AccessControlException unless you grant write access to
> the index
> ------------------------------------------------------------------------------------
>
> Key: LUCENE-6542
> URL: https://issues.apache.org/jira/browse/LUCENE-6542
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/store
> Affects Versions: 5.1
> Reporter: Trejkaz
> Labels: regression
> Attachments: LUCENE-6542.patch, patch.txt
>
>
> Hit this during my attempted upgrade to Lucene 5.1.0. (Yeah, I know 5.2.0 is
> out, and we'll be using that in production anyway, but the merge takes time.)
> Various tests of ours test Directory stuff against methods which the security
> policy won't allow tests to write to. Changes in FSDirectory mean that it now
> demands write access to the directory. 4.10.4 permitted read-only access.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
