I should clarify something. My objections mostly relate to the insistent language in the SIP requiring Solr to have a substitute for the JSM. I'm not quite against doing something but I might vote -0 on something that seems to have a poor security payoff relative to the maintenance burden. The more off-the-shelf, the better IMO. Thank you for investing your time researching some options.
On Wed, Apr 29, 2026 at 9:58 AM David Smiley <[email protected]> wrote: > Rejected Alternatives >> >> - *Staying on Java < 24* — not viable long-term; Solr must support >> current Java LTS releases. >> - *Removing JSM protections without any replacement* — unacceptable >> security regression. >> >> Both Eric Pugh and I have challenged this. > >> >> - *OS-level hardening only (systemd, seccomp)* — not cross-platform; >> does not cover Windows or macOS. >> >> I challenge this. Why should the Solr project burden itself with building > & maintaining security mechanisms already provided by off-the-shelf tools? > If a user/operator wishes to run on Windows/macOS that may not have this > protection mechanism, it is a risk consideration for that user to consider, > but isn't a deal-breaker. The JSM wasn't/isn't a front-line defense; it's > a defense-in-depth strategy. Put differently, the protections here are > "best effort" but not worthy of a CVE if they were to falter. I want to > get Arnout's opinion on this supposition. > >> >> - *Dynamic ZK-watcher-based network policy* — correct but >> significantly more complex; adds ZK client dependency to the agent JAR. >> Superseded by port-based wildcards for intra-cluster traffic. >> - *Building a Java agent from scratch* — higher effort with no >> functional advantage over adapting the Apache 2.0-licensed OpenSearch >> implementation. >> >> I agree with not burdening this project with building & maintainining > such a mechanism. > > I'm not sure, to what degree, we can leverage that existing agent you > speak of without further burdening us. It's a burden/reward trade-off. > > In your updated proposal, you point > out org.apache.solr.core.CoreContainer#assertPathAllowed That is called by > a number of places... although I *think* the original intention was only to > limit where cores are created? Can you elaborate on what the role of that > method *should* be and how the JSM might also or work? > > On Wed, Apr 29, 2026 at 7:35 AM Jan Høydahl <[email protected]> wrote: > >> Hi again, >> >> I sat down with GitHub SpecKit to detail a specification and >> implementation plan for this SIP. >> >> Updated the SIP page: >> https://cwiki.apache.org/confluence/display/SOLR/SIP-24%3A+Java+Security+Manager+replacement >> That page also links to a page on my web site with full details and >> implementation plan. >> I think this is an excellent timing to harden our sandbox as more and >> more users want to move beyond Java21 with no JSM. >> >> Jan >> >> > 1. juli 2025 kl. 16:49 skrev David Eric Pugh <[email protected]>: >> > >> > I was curious what removing the Java Security Manager from Solr would >> entail. >> > Considering all the discussions back and forth about the Java Security >> Manager, I was pleasantly surprised to see how few files it actually >> touched. I was also kind of sad that it was never once mentioned in our >> Ref Guide. >> > https://github.com/apache/solr/pull/3406 is a first pass at removing >> it. >> > Eric >> > >> > On Monday, June 30, 2025 at 06:02:58 PM EDT, Gus Heck < >> [email protected]> wrote: >> > >> > This was the original ticket/discussion over there when the issue first >> > came up in 2021 >> https://github.com/opensearch-project/OpenSearch/issues/1687 >> > >> > >> > On Mon, Jun 30, 2025 at 4:47 PM Jan Høydahl <[email protected]> >> wrote: >> > >> >> Hi, >> >> >> >> Opensearch has released v3.0 with their new java agent capable of >> >> filtering network and file access. They wrote a blog post about their >> >> thinking here >> >> >> https://opensearch.org/blog/finding-a-replacement-for-jsm-in-opensearch-3-0/ >> >> This is for information / food for thought. Please don't read it as a >> >> proposal for Solr to do exaclty the same. But do let it inform the SIP >> of >> >> what options we have. >> >> >> >> Jan >> >> >> >>> 30. juni 2025 kl. 18:52 skrev David Smiley <[email protected]>: >> >>> >> >>> I think Eric proposes _completely_ removing Solr's references to the >> >>> security manager (and thus not use it) in Solr main/10. Such a move >> >>> wouldn't block pursuing alternatives discussed in the SIP. >> >>> >> >>> On Thu, Jun 5, 2025 at 11:45 AM Houston Putman <[email protected]> >> >> wrote: >> >>> >> >>>> Sorry for the late reply, been vacationing and busy! >> >>>> >> >>>> Thanks for getting this going Jan. This is a great SIP. >> >>>> >> >>>> I've put a good amount of thought into this, especially: >> >>>> >> >>>> >> >>>>> - Limit what file paths can be read/written >> >>>>> >> >>>>> >> >>>> And I don't think it's an easy thing to solve, but something we >> >> certainly >> >>>> need to care about. And hopefully this new solution will work better >> >> with >> >>>> the Solr system properties (comma separated list of paths), that the >> >>>> Security Manager couldn't do. >> >>>> >> >>>> - Houston >> >>>> >> >>>> On Thu, Jun 5, 2025 at 7:59 AM David Smiley <[email protected]> >> wrote: >> >>>> >> >>>>>> I know you have under "Rejected Alternatives" the statement >> "Leaving >> >>>> Solr >> >>>>> unprotected", but honestly, I think that is just too broad of a >> >>>> statement. >> >>>>> >> >>>>> >> >>>>> I completely agree; that felt wrong when I read that. The >> >>>> SecurityManager >> >>>>> is not Solr's front-line protection mechanism -- that's >> authentication >> >> & >> >>>>> authorization plugins. The SM was always an auxiliary nice-to-have >> >>>>> secondary to that. It's also well within the user's power to add >> >> general >> >>>>> purpose mechanisms requiring no special enablement within Solr >> >>>> whatsoever: >> >>>>> such as mTLS via Istio. >> >>>>> >> >>>>> On Thu, Jun 5, 2025 at 7:17 AM David Eric Pugh >> <[email protected] >> >>> >> >>>>> wrote: >> >>>>> >> >>>>>> Ten is the perfect time to rip it out. Let's separate ripping it >> out >> >>>>>> from "whatever else we decide"... Otherwise we'll bike shed it to >> >>>> death! >> >>>>>> I know you have under "Rejected Alternatives" the statement >> "Leaving >> >>>> Solr >> >>>>>> unprotected", but honestly, I think that is just too broad of a >> >>>>> statement. >> >>>>>> >> >>>>>> >> >>>>>> Plus, I don't actually see why ideas like "Build a custom Java >> Agent" >> >>>> are >> >>>>>> really needed... I think we look at what the rest of the >> Java-world >> >> is >> >>>>>> doing and copy them. And if that is "they never adopted JSM and >> >>>>> therefore >> >>>>>> are not impacted" then let's do that. Let's NOT build a custom >> Java >> >>>>> Agent >> >>>>>> ;-). If there is a great maintained third party project that does >> >>>> great >> >>>>>> stuff we could leverage, like any other depenendency, then let's do >> >>>> that >> >>>>>> instead. And if there isn't anything, well, maybe we are just >> >>>> following >> >>>>>> the path of the Java-world.... >> >>>>>> >> >>>>>> >> >>>>>> On Wednesday, June 4, 2025 at 11:54:21 PM EDT, David Smiley < >> >>>>>> [email protected]> wrote: >> >>>>>> >> >>>>>> Thanks for raising this topic and putting time into it. >> >>>>>> >> >>>>>> IMO the most useful thing to add is a test taming protection >> mechanism >> >>>>> that >> >>>>>> ensures that tests don't write to places in the project that >> should be >> >>>>>> read-only. Basically, if "git" would flag a change, then the test >> is >> >>>>>> at-fault. This was a fantastic benefit of the security manager. >> I've >> >>>>> made >> >>>>>> this mistake before and surely it happened before the SM was used >> in >> >>>> this >> >>>>>> way: you write a test that uses one of the Solr home templates, but >> >> not >> >>>>>> intending to actually write data there but it happens. The >> insidious >> >>>>> part >> >>>>>> is then another test comes along and reads data that shouldn't be >> >>>>> there. I >> >>>>>> started chatting with Gemini on a solution involving a Gradle >> plugin >> >>>> that >> >>>>>> would run "git status" before & after. I may explore that further. >> >>>> If I >> >>>>>> don't... ah well; whatever. Move on. >> >>>>>> >> >>>>>> I don't put much stock in the original / standard use of the >> >>>>>> SecurityManager. The burden of maintaining its configuration and >> >>>>>> trade-offs has been annoying. The very vast majority of the Java >> >>>>> developer >> >>>>>> world has ignored it, yet we embraced it. Shrug. If you haven't >> >>>>> noticed, >> >>>>>> there aren't a lot of developer/maintenance hours being put into >> Solr >> >>>>>> lately, so let's not overthink a replacement or if there needs to >> be >> >>>> one >> >>>>> in >> >>>>>> any way. 13 days later, you get the only reply (mine) -- case in >> >>>> point. >> >>>>>> Sorry for the sad dose of reality. >> >>>>>> >> >>>>>> ~ David >> >>>>>> >> >>>>>> On Thu, May 22, 2025 at 6:01 AM Jan Høydahl <[email protected] >> > >> >>>>> wrote: >> >>>>>> >> >>>>>>> Hi, >> >>>>>>> >> >>>>>>> Let's kick off a discussion on what protections we'd want to put >> in >> >>>>> place >> >>>>>>> when Java Security Manager is gone in Java 24. >> >>>>>>> >> >>>>>>> Since this is a major topic likely spanning many parts of Solr, I >> >>>> made >> >>>>> a >> >>>>>>> SIP-24 for it: >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-24%3A+Java+Security+Manager+replacemen >> >>>>>>> >> >>>>>>> I do not intend to "lead" this effort, but hoping that >> kick-starting >> >>>>> this >> >>>>>>> discussion will lead to at least a set of JIRA issues being >> created >> >>>> for >> >>>>>>> concrete actions for the most important actions. >> >>>>>>> >> >>>>>>> Jan >> >>>>>> >> >>>>> >> >>>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > -- >> > http://www.needhamsoftware.com (work) >> > https://a.co/d/b2sZLD9 (my fantasy fiction book) >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
