I didn't propose a new configuration file, I proposed a "mode". Even if there was some new env-specific file, it would end up being yet another configuration file -- no thanks. Solr still needs solr.xml & solrconfig.xml & schema.xml (and more), plus Jetty's many config files, and they are mostly for different purposes. Even if we were to hypothesize a brand new system that had one configuration file, what does the code reading this file do if the particular named setting isn't present? *That* question is where a "mode" might in some cases yield a different default depending on the setting.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, May 6, 2021 at 7:02 PM Eric Pugh <ep...@opensourceconnections.com> wrote: > I think that part of the challenge goes to the deeper issue that > configuring Solr isn’t easy. We don’t really have the concept of a > environment specific settings file. I’d love to see a -env=production.yml > or -env=development.yml type file that was the single place for all > settings, and had sane defaults for each environment. Something that > worked across Docker, classic installed service, or just via a bin/solr > start command line ;-). > > I am constantly finding new command line config options that I didn’t know > about ;-) > > > > On May 6, 2021, at 5:58 PM, matthew sporleder <msporle...@gmail.com> > wrote: > > > > On Thu, May 6, 2021 at 5:25 PM David Smiley <dsmi...@apache.org> wrote: > >> > >> 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 > > > > I have also found open solr servers and normally send an email like > > "shall I delete your data or wait for you to do it?" > > > > As solr is primarily an index of other data the primary issue is data > > disclosure. Config editing, inserting data, etc are all pretty > > secondary. > > HTTP Basic Auth with a first-boot-random password is a massively > > simple thing built into jetty that will solve 99% of exposed solr > > servers. > > > > secure-by-default will decrease adoption without major east-to-follow > > warning messages so tread lightly. > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > >
