On 1/17/2013 2:01 PM, snake wrote:
I think your not understanding the issue.Imagine www.acme.com has created a
collection.
This resides in d:\acme.com\wwwroot\collections
Then they decide to redo their website, or they get a new developer who
decides not to use collections, or they simply move hosts, so they delete
the old one.
The collection is now gone.
Solr now cannot find the config files for that collection since they are
gone, so solr crashes and breaks every other website on the entire server
that is using solr.
The customers have no idea this will happen, no knowledge about having to
get collections removed properly etc, so saying "they should do this and
that" simply wont happen so is not a solution.
Solr has no security measures. If you are giving customers direct
access to one or more directories on your Solr server, there are a LOT
of ways that they can cause you problems, intentionally or not.
By adding a jar to their data directory and referencing it in their
config, they can do just about anything. Custom Solr components could
be written that do one or more of the following:
- Tie up all of Solr's memory and cause it to crash.
- Grant general access to the server as the user that runs solr.
- Utilize a security vulnerability and gain admin access.
Changes need to be checked before implementation. If a customer wants
to use custom components, that would require extra scrutiny. I can't
think of any way to fully protect your server without requiring human
intervention for all changes.
Thanks,
Shawn
