> I would like to be able to define core specific permissions with rule-based > authorization in security.json in the same way you can do for collections.
PRs/Patches welcome... but I think you're going to have to accept migrating to SolrCloud. SolrCloud has gotten better year over year. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, May 7, 2021 at 3:39 AM Thomas Corthals <tho...@klascement.net> wrote: > I would like to be able to define core specific permissions with rule-based > authorization in security.json in the same way you can do for collections. > > Thomas > > Op do 6 mei 2021 om 23:25 schreef David Smiley <dsmi...@apache.org>: > > > I'm reaching out to our user community to get opinions on what Solr > should > > do to be more secure-by-default. > > > > TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more > > like have Solr pick some of it's default settings dependent on a new > > env=dev|prod. > > > > I was shown a glimpse of a massive list of Solr servers exposed on the > > public internet by a security researcher. I'm kinda blown away that so > > many people would be so careless. I think Solr could and should run with > > better "secure-by-default" settings. > > > > The situation will be much better in Solr 9 -- and I'll give a shout-out > of > > thanks to Rob Muir for helping make this so. Here's a couple prominent > > ones: > > * Solr's Jetty now binds to localhost by default, configurable via > > SOLR_JETTY_HOST. Before 9, you can configure a similar thing in the > Jetty > > config files. SOLR-13985 > > * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984. > > This option also exists in Solr since 8.5, toggle-able > > via SOLR_SECURITY_MANAGER_ENABLED. Mostly this prevents the worst of > > security bugs -- RCE. > > > > I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get > anything > > done? I think so... but it's something, protecting some users. > > > > Perhaps Solr ought to default to requiring a username/password? I've > heard > > this suggestion and it's an obvious one even if some of us (me included) > > worry that it would make it too annoying to play with Solr when getting > > started. I think the concerns could be mitigated based on the approach. > > If Solr had an opt-in env=dev setting, for example, then Solr could not > > insist on authentication, whereas a default env=prod would insist. Of > > course the authentication or lack thereof could be explicitly configured > or > > disabled at the user's prerogative. What I like about an "env" setting > is > > that many other settings could be gated on this as well. > > > > I particularly like the idea of an env=dev|prod setting because a variety > > of settings in Solr could have a default that is dependent on this value. > > In particular I argue that a env=prod should result in Solr's config APIs > > being disabled -- equivalent to -Ddisable.configEdit=true. I believe a > > minority of Solr users actually use these APIs, yet they are frequently a > > step in exploiting weaknesses in Solr. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > >
