lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (SOLR-5287) Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
Date Mon, 02 Dec 2013 08:40:37 GMT


Uwe Schindler commented on SOLR-5287:

Hi [~dfj],
Thank you for the comment. You are right, this is not part of Solr 4.6.0, otherwise I would
not have made the POC public on this issue tracker. So a CVE is not needed.

I agree with you, too, that powerful admin features that allow deeper modifications to the
hosting system, need to be secured. So although there is already SOLR-5518 that wants to move
this feature to a separate RequestHandler, I don't want to have that in the stable branch.
Please back it out completely for 4.x.

I am fine with letting it bake on the trunk branch and we should spend some efforts to make
"RequestHandler" based security features available. It should be easily possible to add those
security features, because RequestHandlers are encapsulated. We can use the abstract Java
features of to manage users on an abstract way (and fall back
to servlet container). We then just need to check the principal on the ServletRequest and
decide if the RequestHandler is executed and return HTTP Fobidden otherwise. Yu can then configure
users and so on, on the servlet container. If you don't do, all the advanced admin features
are disabled.

The following features should be inaccessible by default:
- admin request handlers, especially stuff like creating cores, deleting indexes,...
- scripted updates (currently disabled by default)
- scripted DIH (needs access to filesystem to enable)

We should investigate this in Solr 5 (aka trunk) and not hurry in backporting those features.
I am happy to help.

> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>                 Key: SOLR-5287
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis, web gui
>    Affects Versions: 4.5, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Blocker
>             Fix For: 5.0, 4.7
>         Attachments: SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch, SOLR-5287.patch,
> A user asking a question on the Solr list got me to thinking about editing the main config
files from the Solr admin screen. I chatted briefly with [~steffkes] about the mechanics of
this on the browser side, he doesn't see a problem on that end. His comment is there's no
end point that'll write the file back.
> Am I missing something here or is this actually not a hard problem? I see a couple of
issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file permission exceptions
if Solr tries to write the file out. Well, do a chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue, this
would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work that []
has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or something
like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with "Don't waste
your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would be a significant
ease-of-use improvement, so there _has_ to be something I'm missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two immediate sub-JIRAs
that spring to mind will be the UI work and the endpoints for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection)
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to take it
over it won't hurt my feelings a bit....

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message