Christon, thank you for verifying it occurs for you as well. You're right that changing the line has no effect, I must have made a mistake testing it before and after, apologies!
After reading a bit about the Java Security Manager it seems like "-" is the correct wildcard to set permissions recursively, but it's clearly not working. Unless anyone else here has a better recommendation, I'll create an account on the Apache Jira to report this to the dev team. On Wed, Oct 23, 2024 at 7:35 PM Christos Malliaridis < c.malliari...@gmail.com> wrote: > I followed the instructions from > > https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-with-tika.html > with the techproducts example and I was able to reproduce the 500 file > permission error. > > However, changing the line had no effect (restarted and rebuilt the project > and instance as well). > > On Wed, Oct 23, 2024 at 12:45 PM govind nitk <govind.n...@gmail.com> > wrote: > > > Thanks for insight: > > > > ``` > > permission java.io.FilePermission "${java.io.tmpdir}${/}*", > > "read,write,delete"; > > > > and this seems to fix the problem. > > ``` > > > > Can anyone confirm on this once ? > > > > > > On Sun, Oct 20, 2024 at 9:40 AM Ivo Janssen <fox...@gmail.com> wrote: > > > > > Govind, > > > > > > Thank you for your speedy response. Indeed that seems to be the > problem - > > > after starting with `-Djava.security.manager=allow` the documents are > > > posting as expected. > > > > > > Is this a bug that should be raised up to the Solr team? I was able to > > > reproduce on another machine running MacOS 15.0.1 as well, so I checked > > the > > > Solr security policy in /server/etc/security.policy, which contains the > > > following line: > > > > > > ``` > > > permission java.io.FilePermission "${java.io.tmpdir}${/}-", > > > "read,write,delete"; > > > ``` > > > > > > (ref: > > > > > > > > > https://github.com/apache/solr/blob/b6e5f9f08339b1407217a2e8d8ec106cd0d0f587/solr/server/etc/security.policy#L32 > > > ) > > > > > > this seems insufficient for MacOS, so I tried changing it to: > > > > > > ``` > > > permission java.io.FilePermission "${java.io.tmpdir}${/}*", > > > "read,write,delete"; > > > ``` > > > > > > and this seems to fix the problem. > > > > > > Anyone else agree this sounds like a bug? > > > > > > On Fri, Oct 18, 2024 at 9:00 PM govind nitk <govind.n...@gmail.com> > > wrote: > > > > > > > Solr server does not have permission to read a specific file in the > > Jetty > > > > temporary directory > > > > for you local setup > > > > try starting solr with java.security.manager=allow > > > > It will disable the security manager entirely and remove all the > > security > > > > checks enforced by it, allowing SOLR to access any files or resources > > > > without restrictions. > > > > > > > > Note that, its *not recommended for prod* envs. > > > > If you have separate policy files, you can add dir/file specific > grant > > > > permissions. > > > > > > > > best, > > > > govind > > > > > > > > > > > > On Sat, Oct 19, 2024 at 6:01 AM Ivo Janssen <fox...@gmail.com> > wrote: > > > > > > > > > Hi all, > > > > > > > > > > I'm using Solr 9.7 on MacOS, with Cell enabled, and it returns a > 500 > > > > error > > > > > when I try to add a document. The error on Solr's side is as > follows: > > > > > > > > > > (full log truncated; can paste the full output if desired) > > > > > ``` > > > > > 2024-10-18 00:49:03.350 INFO (qtp1955990522-40-localhost-1) [c: s: > > r: > > > > > x:test_docstore t:localhost-1] o.a.s.c.PluginBag Going to create a > > new > > > > > requestHandler with {type = requestHandler,name = > > > /update/extract,class = > > > > > solr.extraction.ExtractingRequestHandler,attributes = > {startup=lazy, > > > > > name=/update/extract, > > > > class=solr.extraction.ExtractingRequestHandler},args > > > > > = {defaults={fmap.Last-Modified=last_modified, uprefix=ignored_, > > > > > df=_text_}}} > > > > > 2024-10-18 00:49:03.653 ERROR (qtp1955990522-40-localhost-1) [c: s: > > r: > > > > > x:test_docstore t:localhost-1] o.a.s.s.HttpSolrCall 500 Exception > => > > > > > java.lang.IllegalStateException: > > java.security.AccessControlException: > > > > > access denied ("java.io.FilePermission" > > > > > > > > > > > > > > > > > > > > "/private/var/folders/8y/0166d0yx0wd7lxycs42l6t9c0000gs/T/jetty-127_0_0_1-8983-webapp-_solr-any-16097010865664396603" > > > > > "read") > > > > > at > > > > > > > > > > > > > > > > > > > > org.eclipse.jetty.server.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:526) > > > > > java.lang.IllegalStateException: > > java.security.AccessControlException: > > > > > access denied ("java.io.FilePermission" > > > > > > > > > > > > > > > > > > > > "/private/var/folders/8y/0166d0yx0wd7lxycs42l6t9c0000gs/T/jetty-127_0_0_1-8983-webapp-_solr-any-16097010865664396603" > > > > > "read") > > > > > at > > > > > > > > > > > > > > > > > > > > org.eclipse.jetty.server.MultiPartFormInputStream.throwIfError(MultiPartFormInputStream.java:526) > > > > > ~[jetty-server-10.0.22.jar:10.0.22] > > > > > at > > > > > > > > > > > > > > > > > > > > org.eclipse.jetty.server.MultiPartFormInputStream.getParts(MultiPartFormInputStream.java:491) > > > > > ~[jetty-server-10.0.22.jar:10.0.22] > > > > > at > > > > > > > > > > > > > > > > > > > > org.eclipse.jetty.server.MultiParts$MultiPartsHttpParser.getParts(MultiParts.java:90) > > > > > ~[jetty-server-10.0.22.jar:10.0.22] > > > > > at org.eclipse.jetty.server.Request.getParts(Request.java:2354) > > > > > ~[jetty-server-10.0.22.jar:10.0.22] > > > > > at org.eclipse.jetty.server.Request.getParts(Request.java:2328) > > > > > ~[jetty-server-10.0.22.jar:10.0.22] > > > > > at > > > > > > > > > > > > > > > > > > > > javax.servlet.http.HttpServletRequestWrapper.getParts(HttpServletRequestWrapper.java:317) > > > > > ~[jetty-servlet-api-4.0.6.jar:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.SolrRequestParsers$MultipartRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:649) > > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.SolrRequestParsers$StandardRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:893) > > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.SolrRequestParsers.parse(SolrRequestParsers.java:169) > > > > > ~[?:?] > > > > > at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:313) > > > > ~[?:?] > > > > > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:524) > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:251) > > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilter$0(SolrDispatchFilter.java:208) > > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:243) > > > > > ~[?:?] > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:213) > > > > > ~[?:?] > > > > > ... > > > > > ``` > > > > > > > > > > My limited knowledge of MacOS internals makes me believe it's > related > > > to > > > > > temp file creation/deletion, but the folder in question is indeed > > > > readable > > > > > by the current user. (in fact, Solr seems to be fine with creating > > and > > > > > deleting it, since it disappears when I shut down Solr, and > reappears > > > > again > > > > > when I restart it) > > > > > > > > > > Is this a Solr issue, a Jetty issue, or...? Any thoughts on how to > > > solve? > > > > > > > > > > Any help is much appreciated. > > > > > > > > > > > > > > >
