I love the idea of a separate module, although it isn't a necessity. With such, a future potential CVE could be reported against this module, thus users choosing not to use the module don't get annoying vulnerability scan alerts for modules they don't use. Although it's a separate topic, I could see benefits of modularizing more driven by that motivation (and other motivations of course). For example, imagine if more SolrCloud aspects of solr-core were separated to a jar that standalone mode could run without. It would mean a SolrCloud-specific CVE could be associated to that JAR and not solr-core. Just a thought. And imagine a stripped-down, embedded Solr as well (low dependencies). Of course, realizing such fantasies would require real work, as CoreContainer and other classes assume all public classes are available to it.
I definitely want to be able to configure security purely from local files/environment, excluding ZK. Managing configuration in ZK with evolving cluster upgrades has been problematic from my past experience. By contrast, relying on a locally built & tested Docker image leaves less "state" behind to manage with an upgrade. On Sun, May 3, 2026 at 6:34 PM Gus Heck <[email protected]> wrote: > I find the idea of out of sync security settings terrifying. If it's not > managed by zk then you have to deal with any number of corner cases > involving nodes that lost connectivity, were down, or in K8 world, settings > on the persistent volume that is re-attaching... > > The last thing I want is more than one notion of what the security settings > are. I imagine a json version of the info in shiro.ini in zk. I have a > personal project where I stored the permissions in a database table and > mapped it to hibernate. We could even just put an ini in zk too. > > I definitely would like to have this be an option not a replacement > initially I suspect if it goes well the old system will be sunset at some > point. > > Also not yet mentioned - I would *hope* I can make it a module (and move > the current one to a module too, which might be a separate effort or > necessary for this. > > > On Sun, May 3, 2026 at 6:06 PM Jan Høydahl <[email protected]> wrote: > > > Great that you want to start this effort. > > > > When you say "Add a new plugin based on Apache Shiro", do you then mean > > trying to fit Shiro into our current security.json plugins or to start a > > fully parallel implementation? > > I think perhaps a fully parallel approach (with shiro.ini or some other > > local-to-node config format) being used. I'm starting to question if > having > > the central security.json in ZK is in itself a security risk compared to > > local files on nodes. > > It is also far easier to bootstrap a solr node with security if based on > > local file configuration, than relying on ZK. Perhaps the SIP can discuss > > such tradeoffs. > > > > Jan > > > > > 3. mai 2026 kl. 23:25 skrev Gus Heck <[email protected]>: > > > > > > oops, forgot to put the discuss tag on the subject line, please proceed > > on > > > this thread > > > > > > On Sun, May 3, 2026 at 5:20 PM Gus Heck <[email protected]> wrote: > > > > > >> I spent some time writing up an idea that's been growing in my head > > >> since I watched Jason's talk on our "not so basic auth" at activate in > > 2019 > > >> > > >> > > >> > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-26%3A+Role+Based+Authentication+using+Apache+Shiro > > >> > > >> LMK what you think. I'm hoping to begin spending some time on this > soon. > > >> > > >> -Gus > > >> > > >> -- > > >> http://www.needhamsoftware.com (work) > > >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > > >> > > > > > > > > > -- > > > http://www.needhamsoftware.com (work) > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
