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]
