> If folks are allowed to execute code, they are allowed > to execute until such time as they hit something they don't have access to
Ah, thanks, I appreciate that clarification! "Guard the vault right at the door" sounds really appealing, admittedly. But I have a few concerns in practice: First, it seems hard to reconcile with our current auth framework, which is very much a bouncer checking ID "at the door". Without more detail, it seems like we'd end up with two very different frameworks which would make things hard to reason about. Second, without knowing more it seems like the sort of thing that would be extremely messy. Our code benefits today from being able to assume that if an API call is executing then the user has the appropriate permissions. For the most part, we don't need to litter our code with permissions-checking, handle the failure of such checks, roll back partially completed operations, etc. That would all change in this new world. Thirdly - and most importantly - past history makes me wonder if this would even be secure! The closest thing Solr has today to the "guard the vault door" approach is our "allow path" and "allow URL" settings, which get checked in the midst of API execution right before a particular file-access happens. It's hard to overemphasize how porous these protections have been in practice. Developers don't always remember to put the checks in. Reviewers rarely catch missing checks in PR-review. When checks are present, they often miss subtle issues. They've been a constant headache and source of CVEs. If I haven't misunderstood you entirely (possible!), IMO we need to be really careful here that the sort of "right at access time" checks you're envisioning would avoid these pitfalls somehow. They just don't play to our strengths as a volunteer community the way that the simplicity of the "bouncer at the door" approach does. ---- None of that's intended to say: "we shouldn't do this". I'm more just trying to say: "These are the sort of concerns I'd have upfront that maybe the SIP would address, if we decide on this approach". How do we handle the messiness/complexity. How do we avoid the allowPath-style pitfalls etc. Best, Jason On Tue, May 5, 2026 at 9:28 AM Gus Heck <[email protected]> wrote: > > inline: > > On Tue, May 5, 2026 at 8:50 AM Jason Gerlowski <[email protected]> > wrote: > > > Hey Gus, > > > > Thanks for writing this up and considering implementation Gus! > > > > At a high-level, I notice there's not a ton about Shiro in the SIP. I > > guess I expected to see a bit more on "Here's why Shiro is a good > > choice", or "Here's what Shiro gets us compared to other > > alternatives", or "Here's the bits of Shiro I think we should use". > > That might be good to add at some point. > > > > > Yes! this is a WIP still, and I'm putting it out there to make sure there's > enthusiasm and no major objections before I spend time working out the > details (also easier to get the ball rolling if I don't have to write it > all up in one go). If someone has other ideas, that should be discussed. > I'm familiar with Shiro, so that's a big part of why I favor it. > > > > Lower-level comments on the SIP "inline" below... > > > > > ["Shortcomings" section] Solr will start up (or continue running) with a > > broken security.json > > > > At startup this is definitely true. But once running, if someone > > uploads a malformed security.json Solr will ignore the changes and > > continue enforcing the last well-formed security.json. > > > > I spent a little time playing with this recently. Thought I observed > otherwise, will double check. > > > > > > (Not saying this is great or worth preserving; just pointing out a bit > > of delta from what you described.) > > > > Also - is this related to the SIP? It seems conceptually unrelated > > from a "Shiro RBAC Implementation". > > > > Yeah, it's a slight creep; it could be moved to a separate issue. > > > > > > > ["More Common" section] When the code is reached, the user's roles are > > expanded to a list of permissions and if the role imply the required > > permission the code executes > > > > Can you expand a bit on what this means? (Here or in the SIP, either > > way). In your writeup it seems like this is being contrasted with > > permissions that are checked or applied at the request/API level. It > > sounds like that'd allow for authorization to happen somewhat lazily, > > perhaps even when solr is midway through processing an API call. On > > the surface that seems potentially messy, but perhaps I'm > > misunderstanding... > > > > > One thing I hope to achieve with the new plugin is to add a bunch more > points at which we can check security. These won't be leveraged by the > existing "Rule based" plugin but the idea is to move to guarding the > destination, rather than trying to anticipate every possible path to it. > I'm philosophically against co-opting security into a performance > optimization role. If folks are allowed to execute code, they are allowed > to execute until such time as they hit something they don't have access to, > and THEN we stop the request. If you want to protect the valuables in a > vault, it's far easier to guard the vault itself than to figure out which > entrances provide access to hallways that could lead to the vault (and > which hallways might gain new doorways later). > > > ["Motivation" section] The goal is to provide a new alternative that is > > > > Your writeup leaves off in mid-sentence here. The suspense is killing > > me! :-p > > > > Wait for it... wait for it... (yeah oops, clearly this should be fixed) > > > > > > > ["Proposed Changes" section] Additionally Solr should refuse all > > requests if the security.json fails to parse > > > > Scope-wise, I'm surprised to see this in a SIP about a new plugin > > implementation. Is there a connection between this and a Shiro plugin > > I'm missing, other than that they're both generally auth related? > > > > FYI that there's a bit of a catch-22 problem here. Many folks rely on > > Solr APIs to update their security.json, so a "refuse all requests" > > strategy in this case could cut users off from the main means of > > fixing their security.json and "brick" their cluster. > > > > Yeah also potentially scope creep, but I didn't think our api's allowed > security.json upload? If we have api's that write unparsable or invalid > security.json files, that sounds like a bug. > > > > > > > [Jan and other's discussion of security.json in thread above] I think > > perhaps a fully parallel approach... > > > > I'm not in love with ZK-based security.json by any means, but changing > > how we manage security config is a *huge* expansion of scope in what's > > already a pretty ambitious SIP. It's also a change that'd > > (temporarily at least) double our attack surface from a framework > > perspective. > > > > Unless it's inextricably tied to the Shiro work in some way, I'd be > > leery of bundling this into SIP-26. > > > > > Agreed, my response was mostly because this seemed to be desired. I had not > intended to change how we store our security (aside from providing what > Shiro needs) > > > > Best, > > > > Jason > > > > On Mon, May 4, 2026 at 9:34 PM Gus Heck <[email protected]> wrote: > > > > > > How about this: we make it possible to push the zk security config to a > > > file on all current nodes, Nodes that don't find security in zk consult > > the > > > filesystem as a fallback. Thus the upgrade scenario can be: > > > > > > 1) Push down security to the nodes > > > 2) remove security definitions from zk > > > 3) perform upgrade > > > 4) supply security to zk again to ensure uniform > > > > > > There could also be an optional "clear local security files" command that > > > cleans the per node security files (if zk has security) out to ensure no > > > confusion on subsequent startup. > > > > > > Folks who prever local files just never supply a security definition to > > zk > > > in the first place... > > > > > > On Mon, May 4, 2026 at 10:34 AM David Smiley <[email protected]> wrote: > > > > > > > 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) > > > > > > > > > > > > > > > > > > -- > > > 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) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
