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