You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2015/06/30 02:36:05 UTC
[jira] [Comment Edited] (LUCENE-6542) FSDirectory throws
AccessControlException unless you grant write access to the index
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org