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 <jan....@cominvent.com> 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 <dsmi...@apache.org>: > > > > 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 <hous...@apache.org> > 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 <dsmi...@apache.org> 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 <de...@yahoo.com.invalid > > > >>> 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 < > >>>> dsmi...@apache.org> 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 <jan....@cominvent.com> > >>> 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: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
