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