[
https://issues.apache.org/jira/browse/SOLR-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15537330#comment-15537330
]
Hoss Man commented on SOLR-7826:
--------------------------------
I know i'm late to the party, but FWIW: I think adding a {{\-force}} option and
treating "root" as special still leaves a lot of room for the underlying
problem to occur (and in general i think adding a {{\-force}} option that's
only supported by one (sub-)command is a bad idea -- more on that below) ...
Just rejecting {{root}} won't help if {{solr}} is the effective UID of the
process, but user {{bob}} runs {{bin/solr create}} and the new core directories
wind up owned by {{bob}} but not readable by {{solr}}. Likewise, running as
{{root}} may be perfectly fine, if the original install (foolishly) installed
as {{root}}
What really matters is that if {{bin/solr create}} is used to try and create
new core directories, those new core directories should *really* be owned by
whatever use owns the {{cores}} parent directory, and have the same
{{user:group}} permissions -- because that way, regardless of what effective UI
the solr process is running under, there's no risk that Solr will be able to
_find_ the new core dir, but not _read_ the new core dir.
ie:
* we don't have to do anything special to keep track of what user installed
solr, or treat {{root}} special
* all we have to do is compare {{whoami}} to {{stat -c '%U'}} on the {{cores}}
directory, and complain if they don't match
----
My general thoughts on {{\-force}}:
even if we switch to comparing the current user to the directory owner instead
of treating "root" as special, a {{\-force}} option could still be supported i
guess, but doesn't really seem necessary and in general i would say we should
avoid it unless/until we really think through _all_ of the possible commands
where we might want to enforce some restrictions unless {{-force}} is
specified. because a user who sees that there is a {{-force}} option for some
{{bin/solr}} commands would have a reasonable expectation that they will be
"protected" unless they specify {{-force}} on other risky solr commands as well
(ie: deleting a core that's currently LOADed?, delete ZK nodes currently used
by a collection? downloading files from ZK and overwriting existing files on
disk? uploading a config set and overwritting an existing config set with the
same name? etc...)
In general, i'm -0 to the changes made by this issue - i don't think Solr, on
the whole, is better off with these changes, and I'd encourage the folks who
worked on this jira to consider rolling them back and replacing them with a
{{`whoami` == `stat -c '%U' .../cores`}} type comparison instead.
> 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
> Assignee: Jan Høydahl
> Priority: Minor
> Labels: newdev
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-7826.patch, SOLR-7826.patch
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
