> > 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] > >
