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