[
https://issues.apache.org/jira/browse/SOLR-13989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986578#comment-16986578
]
Robert Muir commented on SOLR-13989:
------------------------------------
{quote}
So I was looking at some of the new package/plugin management. I think
Hadoop/HDFS could be isolated into its own package/plugin. I don't know what is
all involved with it yet. I think moving to contrib could be a first step. It
would be good to isolate it from dependencies in Solr altogether. It looks like
the plugins allow for separate classloader meaning different versions of
dependencies potentially. The one area that isn't in the plugin/package
framework looks like custom security manager policy - I've worked with ES on
the HDFS integration and custom security policy to open up permissions only
when the HDFS integration was needed. Since Solr hasn't had a security manager
really, I don't think the package/plugin integration thought about the security
manager part yet.
{quote}
Hi Kevin! Thanks for the thoughtful comments.
Agreed, you are right. I think if you are looking at an elaborate design for
security in solr that gives minimal permissions to a minimal solr core, and
delegates permissions out to various contribs instead, it might be too early?
At least I'm not that ambitious here. This ain't my first rodeo, and I think
step zero is to first get "something" very basic and flat into production
before trying to add a bunch of specialized java security code.
If you have the expertise and want to catapult ahead, I'm more than happy to
lend a hand! But I don't want to throw a bunch of scary ass infrastructure
(which might be viewed as overengineering) at the project, i'd rather iterate
slowly.
There is a lot to think about here, for example, it seems solr might be able to
suck down code dynamically which presents new threats that I have not thought
about. I know how to make a modular security framework where the policies are
"static" or "final", but if you can invoke a rest api and suck down new code
and new permissions, how the fuck can that be secure? I think some previous
assumptions might simply be invalid and need to be rethought.
I'm just talking about codebases too, you can take it to the next level, and
think about threads/processes etc. If solr tests are today leaking threads, we
know we're not gonna be able to isolate stuff very well already :)
Anyway, apologies for being longwinded. And I absolutely don't want to
discourage you from helping with the effort. There is a good reason that right
now, I am only touching test code! Please, help! If you propose something, I
will do all kinds of boring slave labor to help make it happen. But currently I
am just cleaning stuff up, kinda smoothing out edges and learning where the
weak points are.
And yes, hadoop presents a real practical challenge. Its the least secure code
i've ever dealt with (sorry). its a nightmare for anything that has it as a
dependency. Its like the developers just didn't care.
> Move all hadoop related code to a contrib module
> ------------------------------------------------
>
> Key: SOLR-13989
> URL: https://issues.apache.org/jira/browse/SOLR-13989
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Hadoop Integration
> Reporter: Shalin Shekhar Mangar
> Priority: Major
> Fix For: master (9.0)
>
>
> Spin off from SOLR-13986:
> {quote}
> It seems really important to move or remove this hadoop shit out of the solr
> core: It is really unreasonable that solr core depends on hadoop. that's
> gonna simply block any progress improving its security, because solr code
> will get dragged down by hadoop's code.
> {quote}
> We should move all hadoop related dependencies to a separate contrib module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
