[ 
https://issues.apache.org/jira/browse/SOLR-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234047#comment-15234047
 ] 

Binoy Dalal commented on SOLR-7826:
-----------------------------------

I've made modifications to the script and SolrCLI.java to support this but I 
don't think this approach really solves anything.
Considering that solr was run as an unprivileged user, when creating the cores 
as root without the option, the script throws an error and bails.
But when the option is used, the user will still be unable to create a core 
since the code will throw an AcessDeniedException, so usage of the option makes 
no difference whatsoever.
I think it would make more sense if the user weren't allowed to create cores at 
all using root, or if the AccessDeniedException was caught and a suitable 
warning was provided to the user.

I would like to know your thoughts on this.

> Permission issues when creating cores with bin/solr
> ---------------------------------------------------
>
>                 Key: SOLR-7826
>                 URL: https://issues.apache.org/jira/browse/SOLR-7826
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Shawn Heisey
>            Priority: Minor
>              Labels: newdev
>
> Ran into an interesting situation on IRC today.
> Solr has been installed as a service using the shell script 
> install_solr_service.sh ... so it is running as an unprivileged user.
> User is running "bin/solr create" as root.  This causes permission problems, 
> because the script creates the core's instanceDir with root ownership, then 
> when Solr is instructed to actually create the core, it cannot create the 
> dataDir.
> Enhancement idea:  When the install script is used, leave breadcrumbs 
> somewhere so that the "create core" section of the main script can find it 
> and su to the user specified during install.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to