The SecurityManager has been *very* useful for tests to ensure they don't write to the file system outside the build or temp directories. It's very easy to indirectly do this since tests commonly point to template configurations.
So for now, I'd like to see us continue to run tests with the SecurityManager until there's a replacement. Replacement ideas: (A) a custom Java NIO FileSystem that enforces permissions. That's a lot of work though... (B) (only for CI build server like Crave), a script edits file system permissions such that an OS test user only has enough permissions to be able to run the build and write to appropriate places. (C) git stage all changes so there's nothing pending (CI only, as applicable). Run tests. Check "git status" to see if there were changes, and if so then fail the build. Wouldn't detect a test cleaning up after itself to such a directory. And wouldn't pinpoint the errant test. On Mon, Feb 3, 2025 at 4:52 PM Houston Putman <hous...@apache.org> wrote: > Hello everyone, > > Java 24 is removing the Security Manager. This is pertinent to us, since we > have the SecurityManager enabled by default. > > Because of this we need to disable the Security Manager when running Java > 24+. > > We also probably want to remove it entirely for Solr 10. > > We can do this, but we should really make sure that we still have the same > security guarantees built-in to Solr. We have this already with > allowedPaths, but we should audit the codebase to make sure this assumption > of security is correct. > > The ticket that is managing this is > https://issues.apache.org/jira/browse/SOLR-17641 > > - Houston >
