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 G
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 wrote:
> Hi,
>
> Opensearch has released v3.0 with their new java agent capable of
> filtering network
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
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 wrote:
> Sorry for the late reply, been vacationing
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
ne
> 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
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.
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 fan
